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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Digital Enhanced Cordless Telecommunications 
(DECT). 

The present document is based on EN 300 175 parts 1 [1] to 8 [8] and EN 300 444 [12]. General attachment 
requirements and speech attachment requirements are based on EN 301 406 [11] (replacing TBR 006 [i.2]) and 
EN 300 176-2 [10] (previously covered by TBR 010 [i.3]). Further details of the DECT system may be found in 
TRIOI 178 [i.l]. 

The present document has been developed in accordance to the rules of documenting a profile specification as described 
in ISO/IEC 9646-6 [13]. 

The information in the present document is believed to be correct at the time of publication. However, DECT 
standardization is a rapidly changing area, and it is possible that some of the information contained in the present 
document may become outdated or incomplete within relatively short time-scales. 

The present document is part 3 of a multi-part deliverable covering the New Generation DECT as identified below: 

Part 1: "Wideband speech"; 

Part 2: "Support of transparent IP packet data" ; 

Part 3: "Extended wideband speech services"; 

Part 4: "Software Update Over The Air (SUOTA) and Content Download". 
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1 Scope 

The present document specifies a set of functionalities of the New Generation DECT. 
The New Generation DECT provides the following basic new functionalities: 

• Wideband speech service (part 1). 

• Packet-mode data service supporting Internet Protocol with efficient spectrum usage and high data rates 
(pai-t 2). 

• Extended wideband speech services (part 3). 

All New Generation DECT devices will offer at least one or several of these services. 
The present document describes the part 3: Extended wideband speech services: 

• For the description of the wideband speech service, see TS 102 527-1 [21]. 

• For the description of the support of transparent IP packet data, see TS 102 527-2 [i.4]. 

The part 3 "Extended wideband speech services" is defined as an extension of part 1 "Wideband speech service". All 
devices compliant to part 3 specification (the present document) shall implement at least all mandatory features and 
may implement the optional features defined in part 1 "wideband speech". In addition to that, the present document 
defines additional mandatory or optional features. 

The part 1, and therefore part 3, are also defined as extensions of the "Generic Access Profile (GAP)" [12]. All DECT 
devices offering Wideband speech services (part 1 or part 1 plus part 3) shall also be compliant with the "Generic 
Access Profile (GAP)" [12], and shall offer the DECT standard 32 kbit/s voice service according to GAP. 

All DECT devices claiming to be compliant with this Application Profile will offer at least the basic services defined as 
mandatory. In addition to that, optional features can be implemented to offer additional DECT services. 

The aim of the present document is to guarantee a sufficient level of interoperability and to provide an easy route for 
development of DECT wideband speech applications, with the features of the present document being a common 
fall-back option available in all compliant to this profile equipment. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 
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NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[I] ETSI EN 300 175-1: "Digital Enhanced Cordless Telecommunications (DECT); Common 
Interface (CI); Part 1: Overview". 

[2] ETSI EN 300 175-2: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 2: Physical layer (PHL)". 

[3] ETSI EN 300 175-3: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 3: Medium Access Control (MAC) layer". 

[4] ETSI EN 300 175-4: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 4: Data Link Control (DEC) layer". 

[5] ETSI EN 300 175-5: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 5: Network (NWK) layer". 

[6] ETSI EN 300 175-6: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 6: Identities and addressing". 

[7] ETSI EN 300 175-7: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 7: Security features". 

[8] ETSI EN 300 175-8: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 8: Speech and audio coding and transmission". 

[9] Void. 

[10] ETSI EN 300 176-2: "Digital Enhanced Cordless Telecommunications (DECT); Test 

specification; Part 2: Speech". 

[II] ETSI EN 301 406: "Digital Enhanced Cordless Telecommunications (DECT); Harmonized EN for 
Digital Enhanced Cordless Telecommunications (DECT) covering essential requirements under 
article 3.2 of the R&TTE Directive; Generic radio". 

[12] ETSI EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access 

Profile (GAP)". 

[13] ISO/IEC 9646-6: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 6: Protocol profile test specification". 

[14] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[15] ITU-T Recommendation G.726 (12/1990): "40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code 

Modulation (ADPCM) ". 

[16] ITU-T Recommendation G.71 1 (1 1/1988): "Pulse code modulation (PCM) of voice frequencies". 

[17] ITU-T Recommendation G.722 (1 1/1988): "7 kHz audio-coding within 64 kbit/s". 

[ 1 8] ITU-T Recommendation G.729. 1 (05/2006): "G.729 based Embedded Variable bit-rate coder: An 

8-32 kbit/s scalable wideband coder bitstream interoperable with G.729". 

[19] ISO/IEC JTC1/SC29/WG1 1 (MPEG): International Standard ISO/IEC 14496-3:2005/AMD 

1:2007: "Coding of audio-visual objects - Part 3: Audio; AMENDMENT 1: Low Delay AAC 
profile". 
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[20] ISO/IEC JTC1/SC29AVG1 1 (MPEG): International Standard ISO/IEC 14496-3:2005: 

"Information Technology - Coding of audio-visual objects - Part 3: Audio". 

[21] ETSI TS 102 527-1: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 1: Wideband Speech". 

[22] ETSI TS 122 072: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Call Deflection (CD); Stage 1". 

[23] Void. 

[24] ETSI TS 122 081: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Line Identification supplementary services; Stage 1". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 101 178: "Digital Enhanced Cordless Telecommunications (DECT); A high Level Guide 

to the DECT Standardization". 

[i.2] ETSI TBR 006: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements". 

[i.3] ETSI TBR 010: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements: Telephony applications". 

[i.4] ETSI TS 102 527-2: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 2: Support of transparent IP packet data". 

[i.5] ITU-T Recommendation P.31 1 (06/2005): "Transmission characteristics for wideband 

(150-7000 Hz) digital handset telephones". 

[i.6] ITU-T Recommendation G.729: "Coding of speech at 8 kbit/s using conjugate structure 

algebraic-code-excited linear prediction (CS-ACELP)". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 300 444 [12] and the following apply: 

CALL-INFORMATION completeness principle: independently of the line identification requirements themselves, a 
party (PP or FP) that implements both the "Line identification" feature and the "Call identification" feature, shall - when 
it must send a call identifier for an external call-also send the identifier of the line used for this external call together 
with the call identifier, in the same «CALL INFORM ATION» information element 

NOTE: This only applies if the line identifier is available at the time of sending. 

FP-managed line selection: mode for an outgoing external call, in which the PP does not send any line identifier to the 
FP 

NOTE: PPs implementing the "Line identification" feature may use this mode. PPs not implementing the "Line 

identification" feature (PPs compliant with NG-DECT Part 1 (TS 102 527-1), GAP (EN 300 444) and PPs 
compliant with the present document not implementing the feature) are also said to (always) implicitly 
use FP-managed line selection. 
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line: logical channel, separately accessible from the external world through a dedicated external directory entry 
(e.g. telephone number, uri, etc.) 

NOTE: These lines may be of various types, for example: PSTN, VoIP or ISDN lines. 

multiple call line: line supporting several simultaneous (external) calls 

NOTE: An example of multiple call line is a VoIP line used with the SIP protocol. 

multiple-call mode: configuration mode of a multiple call line from a DECT system point of view, enabling several 
simultaneous incoming or outgoing calls on different PPs (i.e. this possibility is not disabled by configuration) 

new generation DECT: further development of the DECT standard introducing wideband speech, improved data 
services, new slot types and other technical enhancements 

single-call mode: configuration mode of a multiple call line from a DECT system point of view, in which the 
possibility of making several fully parallel call is (temporarily) disabled 

NOTE: This mode may be useful for a user alone in the home. This mode does not prevent several simultaneous 
calls on the same PP. A line which is not "multiple call" (for instance a PSTN line only enabling double 
calls) is also said to be in "single call" mode. 

super-wideband speech: voice service with enhanced quality compared to ADPCM G.726 and allowing the 
transmission of a maximum vocal frequency of at least 14 kHz 

wideband speech: voice service with enhanced quality compared to ADPCM G.726 and allowing the transmission of a 
vocal frequency range of at least 150 Hz to 7 kHz, and fulfilling the audio performance requirements described in the 
ITU-T Recommendation P.31 1 [i.5] 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

M mandatory to support (provision mandatory, process mandatory) 

optional to support (provision optional, process mandatory) 

1 out-of-scope (provision optional, process optional) not subject for testing 
C conditional to support (process mandatory) 

N/A not applicable (in the given context the specification makes it impossible to use this capability) 

Provision mandatory, process mandatory means that the indicated feature service or procedure shall be implemented as 
described in the present document, and may be subject to testing. 

Provision optional, process mandatory means that the indicated feature, service or procedure may be implemented, and 
if implemented, the feature, service or procedure shall be implemented as described in the present document, and may 
be subject to testing. 

NOTE: The used notation is based on the notation proposed in ISO/IEC 9646-7 [14]. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAC Advanced Audio Coding (MPEG) 

AC Authentication Code 

ADPCM Adaptive Differential Pulse Code Modulation 

AI Air Interface 

CC Call Control 

CI Common Interface 

DECT Digital Enhanced Cordless Telecommunications 

DEC Data Link Control 

DTMF Dual Tone Multi-Frequency 

ER Error Resihent (MPEG) 

FP Fixed Part 
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FT Fixed radio Termination 

GAP Generic Access Profile 

lA Implementation Alternative 

IE Information Element 

IP Internet Protocol 

IPUI International Portable User Identity 

ISDN Integrated Services Digital Network 

IWU InterWorking Unit 

LA Location Area 

LD Low Delay (MPEG) 

LLME Lower Layer Management Entity 

MAC Medium Access Control 

MM Mobility Management 

NG New Generation 

NG-DECT New Generation DECT 

NWK NetWorK 

P Public (environment) 

PARK Portable Access Rights Key 

PHL PHysical Layer 

PP Portable Part 

PT Portable radio Termination 

R/B Residential/Business (environment) 

RFP Radio Fixed Part 

S/T ISDN S/T Interface 

SARI Secondary Access Rights Identity 

TCLw weighted Telephone Coupling Loss 

TPUI Temporary Portable User Identity 

TRUP TRansparent UnProtected service 

U ISDN U-Interface 

VoIP Voice over IP 

WB WideBand 



4 Description of Services 

4.1 Enhanced wideband speech 

The present document is defined as an extension of New Generation DECT; part 1 : wideband speech 
(TS 102 527-1 [21]). All devices compliant with the present document shall implement wideband (150 Hz to 7 kHz) 
audio with 16 kHz frequency sampling, and shall implement, at least, the speech coding format according to ITU- 
T Recommendation G.722 [17]. In addition to that, other wideband and superwideband audio codecs, providing even 
better audio quality, may be implemented. 

See TS 102 527-1 [21], clause 4.1 for description about wideband speech. 

4.1 .1 Back-compatibility witin GAP 

The present document is backcompatible with Generic Access Profile (GAP) EN 300 444 [12]. All devices compliant 
with the present document shall implement ADPCM narrowband speech service according to ITU-T recommendation 
G.726 [15], with automatic detection of the capabilities of the other peer. 

4.1 .2 Furtiner eninancement in audio performance requirements 

The present document implements a further enhancement in acustic wideband performance compared to 
TS 102 527-1 [21]. The more demanding audio specifications PP types 2b and 2c (see EN 300 175-8 [8]) shall be 
mandatory after a transition time. With this extra requirement, the acustic performance of the wideband speech service 
will be even better than the ITU standard for wideband audio, ITU-T Recommendation P.31 1 [i.5]. 

See also TS 102 527-1 [21], clause 4.1.1. 
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The present document implements also a further enhancement in acoustic performance for 3,1 kHz narrowband service 
compared to GAP EN 300 444 [12] and TS 102 527-1 [21]. The more demanding audio specifications for PP types Ic 
and Id (see EN 300 175-8 [8]) shall be mandatory after a transition time. With this extra requirement, the acoustic 
performance of PPs compliant with the present document, when operating in 3,1 kHz narrowband service, will be even 
better than classic DECT/GAP specification. 

4.2 Wideband speech scenarios 

See TS 102 527-1 [21], clause 4.2. 

4.3 Extended wideband speech services defined in the present 
document 

The following additional services are provided by the present document, compared to TS 102 527-1 [21]: 

• More demanding audio specifications for both; wideband and narrowband (see clause 4. 1 .2). 

• New simplified, "easy pairing" procedures. 

• New "no-emision" mode in FPs (switching down the dummy bearer when in idle mode). 

• Date and time synchronization. 

• CLIP and CNIP are now mandatory features. 

• Internal call and wideband Internal call (mandatory features). 

• CLIP and CNIP for Internal calls (mandatory features). 

• Generic Event notification mechanism, providing support for: 

Message waiting indication. 

Missed call notification. 

List access service. 

Handling of multiple calls between the same PP and the RFP. 

CLIP and CNIP on call waiting. 

CLIP and CNIP on call transfer. 

Call deflection. 

Call identification and Line identification features. 

CLIR feature. 

Multiple calls and multiple lines features. 

Mutualised parallel calls. 

New system settings and line settings. 

Informative annexes with more examples of flowcharts, including system settings, multiple calls and parallel 
calls. 

The new extended services, take in to account the additional scenarios possible in DECT systems connected to the 
network via VoIP interfaces. 



£75/ 



17 ETSI TS 102 527-3 V1.1.1 (2008-06) 



5 Service and feature definitions 

5.1 New Generation DECT Speech Services 

For the purposes of the present document, the definitions of TS 102 527-1 [21], clause 5.1 shall apply. 



5.2 Network (NWK) features 



For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.2 and EN 300 444 [12], 
clause 4.1, plus the following shall apply: 

Missed call notification [NG1.N.3]: ability to inform a user that a call has been missed. 

Voice message waiting notification [NG1.N.4]: ability to inform a user that a voice message has been left in the voice 
mailbox to which the user has access. 

Date and time synchronization [NG1.N.5]: ability to synchronize the date and time on the DECT system. From FP to 
all registered PP or from one registered PP to the FP. 

Parallel calls [NG1.N.6]: ability to handle in the DECT system two or more simultaneous calls originated or 
terminated in the same PP. 

Common parallel call procedures (external or internal) [NG1.N.7]: set of common procedures for handling PSTN 
double calls, SIP multiple calls on a single line, as well as parallel call situations occurring in a multiple line DECT 

system. 

Call transfer (internal or external) [NG1.N.8]: ability to create a new call while already involved in a call and 
connect the remote party to it (kind of parallel calls). 

3-party conference call (internal or external) [NG1.N.9]: ability to connect the local party and the two remote parties 
of two parallels calls into a single conference (kind of parallel calls). 

Intrusion call [NGl.N.lO]: ability for a PP not participating to an already established call to connect to it (kind of 
parallel calls). Intrusion call is also known as "barging in". 

Call deflection [NGl.N.ll]: ability to redirect an incoming call during the call presentation to another user. 

Line identification [NG1.N.12]: ability to exchange between the PP and FP a line identifier for external calls. 

Call identification [NG1.N.13]: ability to exchange between the PP and FP a call identifier assigned by the FP at call 
setup. 

Multiple lines [NG1.N.14]: abiHty for a DECT System to handle several external lines. 

Multiple calls [NG1.N.15]: ability for a DECT System to handle a line supporting several simultaneous external calls. 

List access service [NG1.N.16]: ability to store information on the DECT system in a set of lists on the FP and manage 
these lists from the PP. 

Calling Line Identity Restriction (CLIR) [NG1.N.17]: abihty for the user to hide the identity of his line (i.e. Calling 
Line Identity Presentation) to the called party. 

5.3 Data Link Control (DLC) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.3 and EN 300 444 [12], 
clause 5.1 shall apply. 
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5.4 Medium Access Control (MAC) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.4 and EN 300 444 [12], 
clause 5.2, plus the following shall apply: 

"no emission" mode [NG1.M.5]: ability to deactivate all radio transmissions in a DECT FP when it does not handle 
any call. Power-down is negotiated and an algorithm is provided, that guarantees a short resynchronization time, if an 
RF-connection is required by any of the peers. 

5.5 Physical Layer (PHL) service definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.5 shall apply. 

5.6 Speech coding and audio feature definitions 

For the purposes of the present document, all definitions of TS 102 527-1 [21], clause 5.6 shall apply. 

5.7 Application features 

For the purposes of the present document, all definitions of EN 300 444 [12], clause 4.2 plus the following shall apply. 

Easy PIN-code registration [NGl.A.l]: ability to invite the user to register a PP that is not registered to a FP. The 
access rights procedure is triggered by PIN entering. 

Easy pairing registration [NG1.A.2]: ability to register a PP that is not registered to a FP by pressing a physical or 
logical button on the PP and on the FP. 

Handset locator [NG1.A.3]: ability to locate physically handsets (have them ring) by pressing a physical or logical 
button on the FP. 



Inter-operability requirements 



6.1 General 

The tables listed in this clause define the status of all protocol elements (i.e. features, services, and procedures) which 
can be: mandatory, optional, conditional under the provision of another protocol element, outside the scope of the 
present document, or not applicable. The status is identified by the status column designations defined in clause 3.2, and 
is described separately for FT and PT. In the case of FT, the status can be different for products intended for the 
Residential/Business (R/B) market or for the Public market segment. 

All optional elements shall be process mandatory according to the procedures described in the present document. 

Protocol elements defined as mandatory, optional or conditional in this clause are further defined in the referenced 
DECT specification, or, if needed, in clause 7 of the present document. 

New Generation DECT wideband speech is defined as a backcompatible enhancement of EN 300 444 [12] (Generic 
Access Profile (GAP)). All procedures not specific of the New Generation DECT, are referenced to their original 
description in EN 300 444 [12] (GAP). 

The requirements of EN 301 406 [11] and EN 300 176-2 [10] shall be met by all equipment conforming to the present 
document. 
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6.2 New Generation DECT Speech Services support status 

The following end-user services shall be supported by "New Generation DECT; part 3: Extended wideband speech 
services" devices shall support the following end-user services. 

Table 1 : Speech service status 



Feature supported 




Status 1 


Item no. 


Name of Service 


Reference 


PT 


FT 1 


R/B 


p 


NG1.1 


Narrow band ADPCM G.726 32 kbit/s voice service 


5.1 [21] 


M 


M 


M 


NG1.2 


Narrow band PCM G.71 1 64 l<bit/s voice service 


5.1 [211 











NG1.3 


Wideband G.722 64 l<bit/s voice service 


5.1 [21] 


M 


M 


M 


NG1.4 


Wideband G.729.1 32 kbit/s voice service 


5.1 [21] 











NG1.5 


IVlPEG-4 ER AAC-LD super wideband 64 kbit/s voice service 


5.1 [21] 











NG1.6 


l\/IPEG-4 ER AAC-LD wideband 32 kbit/s voice service 


5.1 [21] 












6.3 Services to DECT feature implementation mappings 

"New Generation DECT; part 3: Extended wideband speech services" end user services shall be implemented using the 
DECT features and implementation alternatives defined in table 2. 

Table 2: Speech service to DECT features implementation mappings 



Service/DECT Feature mapping | 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.1 Narrow band ADPCIVI 
G.726 32 l<bit/s voice service 


1 




5.1 [21] 


M 


M 


M 


NG1.P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.2 Physical Packet P32 


5.5 [21] 


M 


M 


M 


NG1.M.1 lN_minimum delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 


GAP.M.4 Basic Connections 


5.2 [12] 


M 


M 


M 


NG1 .M.4 Advanced Connections 


5.4 [21] 


C201 


C201 


C201 


NG1 .D.I DLC Service LU1 TRUP Class 
0/min delay 


5.3 [21] 


M 


M 


M 


NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 


NG1.SC.1 ITU-T Recommendation 
G.726 [15] 32 kbit/s ADPCM codec 


5.6 [21] 


M 


M 


M 


NG1.SC.10 PP Audio type la (classic 
GAP handset) 


5.6 [21] 


1 


N/A 


N/A 


NG1.SC.11 PP Audio type 1 b 
(improved GAP handset) 


5.6 [21] 


C702, 
note 1 


N/A 


N/A 


NG1 .SCI 2 PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1 .SCI 3 PP Audio type Id (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1 .SCI 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SCI 8 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 


NG1 .SC.25 PP echo supressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 


NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 






NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 








NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 








NG1.2 Narrow band PCM G.711 
64 kbit/s voice service 


1 




5.1 [21] 













NG1 .P.1 2 level GFSK modulation 


5.5 [211 


M 


M 


M 


NG1.P.3 Physical Pacl<et P64 


5.5 [21] 


M 


M 


M 


NG1.M.1 lN_minimum delay symmetric 
IVIAC service type 


5.4 [21] 


M 


M 


M 


NG1 .IVI.4 Advanced Connections 


5.4 [211 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP Class 
0/min delay 


5.3 [21] 


M 


M 


M 


NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 


NG1.SC.2 ITU-T Recommendation 
G.71 1 [16] 64 l<bit/s PCM codec 


5.6 [21] 


M 


M 


M 


NG1 .SC.8 Detection of Fax/modem 
tone 


5.6 [21] 











NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 


NG1.SC.10PP Audio type la (classic 
GAP handset) 


5.6 [21] 


1 


N/A 


N/A 


NG1.SC.11 PP Audio type 1 b 
(improved GAP handset) 


5.6 [21] 


C702, 
note 1 


N/A 


N/A 


NG1 .SCI 2 PP Audio type 1c (HATS 
3,1 l<Hz handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1 .SCI 3 PP Audio type Id (HATS 
3,1 l<Hz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1 .SCI 7 PP Audio type 3a (HATS 
3,1 l<Hz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SCI 8 PP Audio type 3b (HATS 
3,1 l<Hz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 


NG1 .SC.25 PP echo supressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 


NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 








NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.2 Narrow band PCM G.711 
64 kbit/s voice service 


II 




5.1 [21] 











NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1 .P.4 Physical Packet P67 


5.5 [21] 


M 


M 


M 


NG1.M.3 lpQ_error_detection symmetric 
IVIAC service type 


5.4 [21] 


M 


M 


M 


NG1 .IVI.4 Advanced Connections 


5.4 [21] 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP Class 
0/min delay 


5.3 [21] 


M 


M 


M 


NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 


NG1.SC.2 ITU-T Recommendation 
G.71 1 [16] 64 kbit/s PCM codec 


5.6 [21] 


M 


M 


M 


NG1 .SC.8 Detection of Fax/modem 
tone 


5.6 [21] 











NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 


NG1.SC.10PP Audio type 1a (classic 
GAP handset) 


5.6 [21] 


1 


N/A 


N/A 


NG1.SC.11 PP Audio type 1 b 
(improved GAP handset) 


5.6 [21] 


C702, 
note 1 


N/A 


N/A 


NG1 .SCI 2 PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1 .SCI 3 PP Audio type Id (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1 .SC.1 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.1 8 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 


NG1 .SC.25 PP echo supressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 


NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 








NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.2 Narrow band PCM G.711 
64 kbit/s voice service 


III 




5.1 [21] 











NG1.P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.5 Physical Packet P80 


5.5 [21] 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
IVIAC service type 


5.4 [21] 


M 


M 


M 


NG1 .IVI.4 Advanced Connections 


5.4 [21] 


M 


M 


M 


NG1 .D.3 DLC service LU7 64 kbit/s 
protected bearer service 


5.3 [21] 


M 


M 


M 


NG1.D.6 DLC frame FU7 


5.3 [21] 


M 


M 


M 


NG1.SC.2 ITU-T Recommendation 
G.71 1 [16] 64 kbit/s PCM codec 


5.6 [21] 


M 


M 


M 


NG1 .SC.8 Detection of Fax/modem 
tone 


5.6 [21] 











NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 


NG1.SC.10PP Audio type la (classic 
GAP handset) 


5.6 [21] 


1 


N/A 


N/A 


NG1.SC.11 PP Audio type 1 b 
(improved GAP handset) 


5.6 [21] 


C702, 
note 1 


N/A 


N/A 


NG1 .SCI 2 PP Audio type 1c (HATS 
3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1 .SCI 3 PP Audio type Id (HATS 
3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1 .SCI 7 PP Audio type 3a (HATS 
3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SCI 8 PP Audio type 3b (HATS 
3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.23 FP Audio type 1 b (new 
ISDN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.24 PP echo canceller for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 


NG1 .SC.25 PP echo supressor for FP, 
narrowband 


5.6 [21] 


N/A 


C707 


C707 


NG1 .SC.26 FP Audio type 2 (analog 
PSTN 3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.27 FP Audio type 3 (VoIP 
3,1 kHz) 


5.6 [21] 


N/A 


C706 


C706 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 








NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 









£75/ 



23 



ETSI TS 102 527-3 V1.1.1 (2008-06) 



Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.3 Wideband 7 kHz G.722 
64 kbit/s voice service 


1 




5.1 [21] 


M 


M 


M 


NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.3 Physical Packet P64 


5.5 [21] 


M 


M 


M 


NG1.M.1 lN_minimum delay symmetric 
MAC service type 


5.4 [21] 


M 


M 


M 


NG1 .M.4 Advanced Connections 


5.4 [21] 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP Class 
0/min delay 


5.3 [21] 


M 


M 


M 


NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 


NG1.SC.3 ITU-T Recommendation 
G.722 [17] 64 kbit/s 7 kHz wideband 
codec 


5.6 [21] 


M 


M 


M 


NG1 .SC.7 Packet loss Concealment 
(PLC) for ITU-T Recommendation 
G.722 [17] 


5.6 [21] 











NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 


NG1 .SCI 4 PP Audio type 2a 
(ITU-T Recommendation P. 311 [i.5] 
7 kHz handset) 


5.6 [21] 


C703, 
note 2 


N/A 


N/A 


NG1 .SC.1 5 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1 .SC.1 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1 .SC.1 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.30 NG1 .SC.24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 


NG1.SC.31 NG1.SC.24PPecho 
supressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 








NG1 .SC.34 Adaptive volume control 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.3 Wideband 7 kHz G.722 
64 kbit/s voice service 


II 




5.1 [21] 











NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.3 Physical Packet P67 


5.5 [21] 


M 


M 


M 


NG1.M.3 lpQ_error_detection symmetric 
IVIAC service type 


5.4 [21] 


M 


M 


M 


NG1 .IVI.4 Advanced Connections 


5.4 [21] 


M 


M 


M 


NG1.D.1 DLC Service LU1 TRUP Class 
0/min delay 


5.3 [21] 


M 


M 


M 


NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 


NG1.SC.3 ITU-T Recommendation 
G.722 [17] 64 kbit/s 7 kHz wideband 
codec 


5.6 [21] 


M 


M 


M 


NG1 .SC.7 Packet loss Concealment 
(PLC) for ITU-T Recommendation 
G.722 [17] 


5.6 [21] 











NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 


NG1 .SCI 4 PP Audio type 2a 
(ITU-T Recommendation P. 311 [i.5] 
7 kHz handset) 


5.6 [21] 


C703, 
note 2 


N/A 


N/A 


NG1 .SC.1 5 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1 .SC.1 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1 .SC.1 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.30 NG1 .SC.24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 


NG1.SC.31 NG1.SC.24PPecho 
supressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 








NG1 .SC.34 Adaptive volume control 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.4 Wideband 7 kHz G.729.1 
32 kbit/s voice service 


1 




5.1 [21] 











NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.3 Physical Packet P32 


5.5 [21] 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
IVIAC service type 


5.4 [21] 


M 


M 


M 


NG1 .IVI.4 Advanced Connections 


5.4 [21] 


M 


M 


M 


NG1 .D.4 DLC service LU12 (UNF) 
Class 


5.3 [21] 


M 


M 


M 


NG1 .D.7 DLC frame FU12 with 
adaptation for codec G.729.1 


5.3 [21] 


M 


M 


M 


NG1.SC.4 ITU-T Recommendation 
G.729.1 [18] 32 kbit/s 7 kHz wideband 
codec 


5.6 [21] 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 


NG1.SC.14PP Audio type 2a 
(ITU-T Recommendation P. 311 [i.5] 
7 kHz handset) 


5.6 [21] 


C703, 
note 2 


N/A 


N/A 


NG1 .SCI 5 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1 .SCI 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1 .SCI 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.30 NG1 .SC.24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 


NG1.SC.31 NG1.SC.24PPecho 
supressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 








NG1 .SC.34 Adaptive volume control 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.5 Superwideband 14 khHz 
MPEG-4 ER AAC-LD 64 kbit/s 
voice service 


1 




5.1 [21] 











NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.3 Physical Packet P64 


5.5 [21] 


M 


M 


M 


NG1.M.2 lN_normal_delay symmetric 
IVIAC service type 


5.4 [21] 


M 


M 


M 


NG1 .IVI.4 Advanced Connections 


5.4 [21] 


M 


M 


M 


NG1.D.2 DLC Service LU1 Class 


5.4 [21] 


M 


M 


M 


NG1.D.5DLC frame FU1 


5.3 [21] 


M 


M 


M 


NG1.SC.5 MPEG4 AAC-LD 64 kbit/s 14 
kHz superwideband codec 


5.6 [21] 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 


NG1.SC.21 PP Audio type 5a 
(Superwideband 14 KHz handset) 


5.6 [21] 


M 


N/A 


N/A 


NG1.SC.22PP Audio type 5b 
(Superwideband 14 KHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 








NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 








NG1.5 Superwideband 14 kHz 
MPEG-4 ER AAC-LD 64 kbit/s 
voice service 


II 




5.1 [21] 











NG1 .P.I 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.3 Physical Packet P67 


5.5 [21] 


M 


M 


M 


NG1 .IVI.3 lpQ_error_detection symmetric 
IVIAC service type 


5.4 [21] 


M 


M 


M 


NG1 .IVI.4 Advanced Connections 


5.4 [21] 


M 


M 


M 


NG1.D.2 DLC service LU1 Class 


5.3 [21] 


M 


M 


M 


NG1.D.5 DLC frame FU1 


5.3 [21] 


M 


M 


M 


NG1 .SC.5 MPEG4 AAC-LD 64 kbit/s 
14 kHz superwideband codec 


5.6 [21] 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 


NG1.SC.21 PP Audio type 5a 
(Superwideband 14 KHz handset) 


5.6 [21] 


M 


N/A 


N/A 


NG1.SC.22PP Audio type 5b 
(Superwideband 14 KHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 








NG1 .SC.34 Adaptive volume control for 
FP 


5.6 [21] 


N/A 
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Service/DECT Feature mapping 




Status 1 


Service 


lA 


DECT feature/service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.6 Wideband 11 kHz MPEG-4 
ER AAC-LD 32 kbit/s voice 
service 


1 




5.1 [21] 











NG1 .P.1 2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.3 Physical Packet P32 


5.5 [21] 


M 


M 


M 


NG1.IVI.2 lN_normal_delay symmetric 
IVIAC service type 


5.4 [21] 


M 


M 


M 


NG1 .IVI.4 Advanced Connections 


5.4 [21] 


M 


M 


M 


NG1.D.2 DLC service LU1 Class 


5.4 [21] 


M 


M 


M 


NG1.D.5DLC frame FU1 


5.3 [21] 


M 


M 


M 


NG1 .SC.6 MPEG4 AAC-LD 32 kbit/s 
1 1 kHz wideband codec 


5.6 [21] 


M 


M 


M 


NG1 .SC.9 Codec selection and 
switching 


5.6 [21] 


M 


M 


M 


NG1.SC.14PP Audio type 2a 
(ITU-T Recommendation P. 311 [i.5] 
7 kHz handset) 


5.6 [21] 


C703, 
note 2 


N/A 


N/A 


NG1 .SCI 5 PP Audio type 2b (HATS 
7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1 .SCI 6 PP Audio type 2c (HATS 
7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1 .SCI 9 PP Audio type 4a (HATS 
7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.20 PP Audio type 4b (HATS 
7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1 .SC.28 FP Audio type 4 (ISDN 
wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.29 FP Audio type 5 (VoIP 
wideband) 


5.6 [21] 


N/A 


C708 


C708 


NG1 .SC.30 NG1 .SC.24 PP echo 
canceller for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 


NG1. SC.31 NG1.SC.24PPecho 
supressor for FP, wideband 


5.6 [21] 


N/A 


C709 


C709 


NG1 .SC.32 FP Audio type 6a (internal 
call) 


5.6 [21] 


N/A 


M 


M 


NG1 .SC.33 FP Audio type 6b (internal 
conference) 


5.6 [21] 


N/A 








NG1 .SC.34 Adaptive volume control 


5.6 [211 


N/A 








lA = Implementation Alternative: 

C201 : Advanced connections for Service NG1 .1 shall only be used in the case of multiple connections 

between the same PT-FT pair. The support of this case is optional. 
C702: At least one should be provided. NG1.SC.11 (type 1b) is only allowed temporarely (see note 1). 
C703: At least one should be provided. NG1.SC.14 (type 2a) is only allowed temporarely (see note 2). 
C706: At least one should be provided. 
C707: IF feature NG1 .SC.23 (FP type 1 b) OR NG1 .SG.27 (FP type 3) THEN ELSE 1. Either NG1 .SG.24 or 

NG1 .SC.25 may be provided, but not both at the same time. 
C708: At least one should be provided. 
C709: IF feature NG1 .SC.28 (FP type 4) OR NG1 .SC.29 (FP type 5) THEN ELSE 1. Either NG1 .SC.30 or 

NG1 .SC.31 may be provided, but not both at the same time. 


NOTE 1 : Feature NG1-SC.11 (type 1b) shall become "1" for PP instead of "C702" after 31-December-2009. 

NOTE 2: Feature NG1-SC.14 (type 2a) shall become "1" for PP instead of "C703" after 31-December-2009. 

NOTE 3: The transition dates given in notes 1 and 2 are linked to the product development and test dates, 
(based on corresponding ETSI test specification EN 300 176-2 [10]). Example for note 1 : For PPs 
developed and tested before 31-December-2009, the feature NG1 .SC.1 1 is C702. For PPs developed 
and tested after 31-December-2009, this feature is 1. 
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6.4 



NWK features 



"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Network 
layer features. 

Table 3: NWK features status 



Feature supported 




Status 1 


Item no. 


Name of feature 


Reference 


PT 


FT 1 


R/B 


P 


NG1.N.1 


Codec Negotiation 


5.2 [21] 


M 


M 


M 


NG1.N.2 


Codec Switcliing 


5.2 [211 


M 


M 


M 


NG1.N.3 


IVIissed call notification 


5.2 


M 


M 


M 


NG1.N.4 


Voice message waiting notification 


5.2 


M 


M 


M 


NG1.N.5 


Date and Time synchronization 


5.2 


M 


M 


M 


NG1.N.6 


Parallel calls 


5.2 


M 


M 





NG1.N.7 


Common parallel call procedures (external or internal) 


5.2 


M 


M 





NG1.N.8 


Call transfer (external or internal) 


5.2 


M 


M 





NG1.N.9 


3-party conference with established external and/or internal 
calls 


5.2 











NG1.N.10 


Intrusion call 


5.2 











NG1.N.11 


Call deflection (external or internal) 


5.2 











NG1.N.12 


Line identification 


5.2 





M 


M 


NG1.N.13 


Call identification 


5.2 





M 


M 


NG1.N.14 


Multiple Lines 


5.2 











NG1.N.15 


IVIultiple calls 


5.2 


M 








NG1.N.16 


List access service 


5.2 


M 


M 





NG1.N.17 


Calling line identity restriction 


5.2 











GAP.N.1 


Outgoing call 


4.1 [12] 


M 


M 


M 


GAP.N.2 


Off hook 


4.1 [12] 


M 


M 


M 


GAP.N.3 


On hook (full release) 


4.1 [12] 


M 


M 


M 


GAP.N.4 


Dialled digits (basic) 


4.1 [12] 


M 


M 


M 


GAP.N.5 


Register recall (see notes 4 and 5) 


4.1 [12] 


M 








GAP.N.6 


Go to DTMF signalling (defined tone length) (see note 1) 


4.1 [12] 


M 





M 


GAP.N.7 


Pause (dialling pause) (see note 3) 


4.1 [12] 


M 








GAP.N.8 


Incoming call 


4.1 [12] 


M 


M 


M 


GAP.N.9 


Authentication of PP 


4.1 [12] 


M 





M 


GAP.N10 


Authentication of user (see note 2) 


4.1 [12] 


M 








GAP.N.11 


Location registration 


4.1 [12] 


M 





M 


GAP.N.12 


On air key allocation (see note 2) 


4.1 [12] 


M 








GAP.N.13 


Identification of PP 


4.1 [12] 


M 








GAP.N.14 


Service class indication/assignment 


4.1 [12] 


M 





M 


GAP.N.15 


Alerting 


4.1 [12] 


M 


M 


M 


GAP.N.16 


ZAP (see note 2) 


4.1 [12] 


M 








GAP.N.17 


Encryption activation FT initiated 


4.1 [12] 


M 


C301 


M 


GAP.N.18 


Subscription registration procedure on-air 


4.1 [12] 


M 


M 


M 


GAP.N.19 


Link control 


4.1 [12] 


M 


M 


M 


GAP.N.20 


Terminate access rights FT initiated (see note 2) 


4.1 [12] 


M 








GAP.N.21 


Partial release 


4.1 [12] 











GAP.N.22 


Go to DTIVIF (infinite tone length) 


4.1 [12] 











GAP.N.23 


Go to Pulse 


4.1 [12] 











GAP.N.24 


Signalling of display characters 


4.1 [12] 











GAP.N.25 


Display control characters 


4.1 [12] 











GAP.N.26 


Authentication of FT 


4.1 [12] 











GAP.N.27 


Encryption activation PT initiated 


4.1 [12] 











GAP.N.28 


Encryption deactivation FT initiated 


4.1 [12] 











GAP.N.29 


Encryption deactivation PT initiated 


4.1 [12] 











GAP.N.30 


Calling Line Identification Presentation (CLIP) 


4.1 [12] 


M 


M 


M 


GAP.N.31 


Internal call 


4.1 [12] 


M 


M 


M 


GAP.N.32 


Service call 


4.1 [12] 
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Feature supported 




Status 1 


Item no. 


Name of feature 


Reference 


PT 


FT 1 


R/B 


P 


GAP.N.33 


Enhanced U- plane connection 


4.1 [12] 











GAP.N.34 


Calling Name Identification Presentation (CNIP) 


4.1 [12] 


M 


M 


M 


C301: IF DECT system "PIN code" setting (clause 7.4.11.3.1) is implemented THEN "M" ELSE "0". 


NOTE 1 : The PT is only required to be able to send the «MULTI-KEYPAD» information element containing the 

DECT standard 8-bit character (EN 300 175-5 [5], annex D) codings "Go to DTMF", defined tone length 

and the FT is required to be able to understand it in the public environment. 
NOTE 2: This feature is required to be supported in the PT to guarantee the same level of security among all the 

handsets that operates in a system. The invocation of the feature is however optional to the operator. 
NOTE 3: The PT is required to be able to send the «IVIULTI-KEYPAD» information element containing the DECT 

standard 8-bit character (EN 300 175-5 [5], annex D) codings "Dialling Pause". This guarantees 

automatic access to secondary or alternative networks. 
NOTE 4: This feature uses keypad code 1 5 hex. 
NOTE 5: The FT is not mandated to receive and understand the register recall DECT character. However, if a FT 

supports it there may be no corresponding action that the FT can take with the local network as a result of 

this function. 



6.5 Data Link Control (DLC) services 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following DLC services. 

Table 4: DLC services status 



Service supported 




Status 1 


Item no. 


Name of service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.D.1 


LU1 Transparent Unprotected service (TRUP) Class 
/minimum delay 


5.3 [21] 


M 


M 


M 


NG1.D.2 


LU1 Transparent Unprotected service (TRUP) Class 


5.3 [21] 


C401 


C401 


C401 


NG1.D.3 


LU7 64 kbit/s protected bearer service 


5.3 [21] 


C401 


C401 


C401 


NG1.D.4 


LU 12 Unprotected Framed service (UNF) Class 


5.3 [21] 


C401 


C401 


C401 


NG1.D.5 


FU1 DLC frame 


5.3 [21] 


M 


M 


M 


NG1.D.6 


FU7 DLC frame 


5.3(21] 


C401 


C401 


C401 


NG1.D.7 


FU12 DLC frame with adaptation for codec G.729.1 


5.3 [21] 


C401 


C401 


C401 


GAP.D.1 


LAPC class A service and Lc 


5.1 [12] 


M 


M 


M 


GAP.D.2 


Cs channel fragmentation and recombination 


5.1 [12] 


M 


M 


M 


GAP.D.3 


Broadcast Lb service 


5.1 [12] 


M 


M 


M 


GAP.D.4 


Intra-cell voluntary connection handover 


5.1 [12] 


M 


C402 


C402 


GAP.D.5 


Intercell voluntary connection handover (note) 


5.1 [12] 


M 








GAP.D.6 


Encryption activation 


5.1 [12] 


M 


C404 


M 


GAP.D.9 


Encryption deactivation 


5.1 [12] 


C403 


C403 


C403 


C401 
C402 
C403 
C404 


Status defined by clause 6.3, table 2. 

IF service GAP.M.9 THEN ELSE M. 

IF feature GAP.N.29 OR GAP.N.28 THEN M ELSE 1. 

IF feature GAP.N.1 7 OR GAP.N.27 THEN M ELSE 1. 


NOTE: The PT is required to be able to support handover between RFPs. The invocation of the feature is 
however optional to the operator. 
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6.6 Medium Access Control (MAC) services 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following MAC layer 

services. 

Table 5: MAC services status 



Service supported 




Status 1 


Item no. 


Name of service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.M.1 


In minimum delay symmetric MAG service type 


5.4 [21] 


M 


M 


M 


NG1.M.2 


In normal delay symmetric MAC service type 


5.4 [211 


C501 


C501 


C501 


NG1.M.3 


IpQ error detection symmetric MAG service type 


5.4 [21] 


C501 


C501 


C501 


NG1.M.4 


Advanced connections 


5.4 [21] 


M 


M 


M 


NG1.M.5 


"no emission" mode 


5.4 











GAP.M.1 


General 


5.2 [12] 


M 


M 


M 


GAP.M.2 


Continuous broadcast 


5.2 [[12] 


M 


M 


M 


GAP.M.3 


Paging broadcast 


5.2 [12] 


M 


M 


M 


GAP.M.4 


Basic connections 


5.2 [12] 


M 


M 


M 


GAP.M.5 


Cs higher layer signalling 


5.2 [12] 


M 


M 


M 


GAP.M.6 


Quality control 


5.2 [12] 


M 


M 


M 


GAP.M.7 


Encryption activation 


5.2 [12] 


M 


C505 


M 


GAP.M.8 


Extended frequency allocation (note) 


5.2 [12] 


M 








GAP.M.9 


Bearer Handover, intra-cell 


5.2 [12] 


M 


C502 


C502 


GAP.M.10 


Bearer Handover, inter-cell 


5.2 [12] 


M 








GAP.M.1 1 


Connection Handover, intra-cell 


5.2 [12] 


M 


C503 


C503 


GAP.M.12 


Connection Handover, inter-cell 


5.2 [12] 


M 








GAP.M.13 


SARI support 


5.2 [12] 


M 








GAP.M.14 


Encryption deactivation 


5.2 [12] 


C504 


C504 


C504 


C501 : Status defined by clause 6.3, table 2. 
C502: IF service GAP.M.1 1 THEN ELSE M. 
C503: IF service GAP.M.9 THEN ELSE M. 
C504: IF feature GAP.N.29 OR N.28 THEN M ELSE 1. 
C505: IF feature GAP.N.1 7 OR N.27 THEN M ELSE 1. 


NOTE: Handsets not supporting these extra frequencies need only adapt scanning to allow continued use of the 
standard DECT frequencies. 



6.7 Physical layer (PHL) services 



"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Physical layer 
(PHL) services. 

Table 6: PHL services status 



Service supported 




Status 


Item no. 


Name of service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.P.1 


2 level GFSK modulation 


5.5 [21] 


M 


M 


M 


NG1.P.2 


Physical Packet P32 


5.5 [21] 


M 


M 


M 


NG1.P.3 


Physical Packet P64 


5.5 [21] 


M 


M 


M 


NG1.P.4 


Physical Packet P67 


5.5 [21] 











NG1.P.5 


Physical Packet P80 


5.5 [21] 












The requirements of EN 300 444 [12], clause 11 also apply. 
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6.8 Speech coding and audio features 

"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Speech 
coding and audio related features. 

Table 7: Speech Coding and audio features 



Service supported 




Status 1 


Item no. 


Name of service 


Reference 


PT 


FT 1 


R/B 


P 


NG1.SC.1 


G.726 32 kbit/s ADPCM codec 


5.6 [21] 


M 


M 


M 


NG1.SC.2 


G.71 1 64 kbit/s PCIVI codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.3 


G.722 64 kbit/s 7 kHz wideband codec 


5.6 [21] 


M 


M 


M 


NG1.SC.4 


G. 729.1 32 kbit/s 7 kHz wideband codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.5 


MPEG4 AAC-LD 64 kbit/s 14 kHz superwideband codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.6 


MPEG4 AAC-LD 32 kbit/s 1 1 kHz wideband codec 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.7 


Packet Loss Concealment (PLC) for G.722] 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.8 


Detection of Fax/modem tone 


5.6 [21] 


C701 


C701 


C701 


NG1.SC.9 


Codec selection and switching 


5.6 [21] 


M 


M 


M 


NG1.SC.10 


PP Audio profile type la (classic GAP handset) 


5.6 [211 


1 


N/A 


N/A 


NG1.SC.11 


PP Audio profile type lb (improved GAP handset) 


5.6 [21] 


C702, 
note 1 


N/A 


N/A 


NG1.SC.12 


PP Audio profile type 1c (HATS 3,1 kHz handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1.SC.13 


PP Audio profile type Id (HATS 3,1 kHz improved handset) 


5.6 [21] 


C702 


N/A 


N/A 


NG1.SC.14 


PP Audio profile type 2a (ITU-T Recommendation P.31 1 [1.5] 
7 kHz handset) 


5.6 [21] 


C703, 
note 2 


N/A 


N/A 


NG1.SC.15 


PP Audio profile type 2b (HATS 7 kHz handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1.SC.16 


PP Audio profile type 2c (HATS 7 kHz improved handset) 


5.6 [21] 


C703 


N/A 


N/A 


NG1.SC.17 


PP Audio profile type 3a (HATS 3,1 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1.SC.18 


PP Audio profile type 3b (HATS 3,1 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1.SC.19 


PP Audio profile type 4a (HATS 7 kHz handsfree) 


5.6 [21] 





N/A 


N/A 


NG1.SC.20 


PP Audio profile type 4b (HATS 7 kHz improved handsfree) 


5.6 [21] 





N/A 


N/A 


NG1.SC.21 


PP Audio profile type 5a superwideband (14 kHz) handset 


5.6 [21] 


C704 


N/A 


N/A 


NG1.SC.22 


PP Audio profile type 5b superwideband (14 kHz) handsfree 


5.6 [21] 


C705 


N/A 


N/A 


NG1.SC.23 


FP Audio type 1 b (new ISDN 3,1 kHz) 


5.6 


N/A 


C706 


C706 


NG1.SC.24 


PP echo canceller for FP, narrowband 


5.6 


N/A 


C707 


C707 


NG1.SC.25 


PP echo supressor for FP, narrowband 


5.6 


N/A 


C707 


C707 


NG1.SC.26 


FP Audio type 2 (analog PSTN 3,1 kHz) 


5.6 


N/A 


C706 


C706 


NG1.SC.27 


FP Audio type 3 (VoIP 3,1 kHz) 


5.6 


N/A 


C706 


C706 


NG1.SC.28 


FP Audio type 4 (ISDN wideband) 


5.6 


N/A 


C708 


C708 


NG1.SC.29 


FP Audio type 5 (VoIP wideband) 


5.6 


N/A 


C708 


C708 


NG1.SC.30 


PP echo canceller for FP, wideband 


5.6 


N/A 


C709 


C709 


NG1.SC.31 


PP echo supressor for FP, wideband 


5.6 


N/A 


C709 


C709 


NG1.SC.32 


FP Audio type 6a (internal call) 


5.6 


N/A 


M 


M 


NG1.SC.33 


FP Audio type 6b (internal conference) 


5.6 


N/A 








NG1.SC.34 


Adaptive volume control for FP 


5.6 


N/A 








C701 
C702 
C703 
C704 
C705 
C706 
C707 

C708 
C709 


Status defined by clause 6.3, table 2. 

At least one should be provided. NG1.SC.11 (type 1b) Is only allowed temporarely (see note 1). 

At least one should be provided. NG1 .SC.14 (type 2a) is only allowed temporarely (see note 2). 

IF Service NG1.5 (Superwideband) THEN M ELSE 1. 

IF Service NG1.5 (Superwideband) THEN ELSE \. 

At least one should be provided. 

IF feature NG1 .SC.23 (FP type 1 b) OR NG1 .SC.27 (FP type 3) THEN ELSE \. Either NG1 .SC.24 or 

NG1 .SC.25 may be provided, but not both at the same time. 

At least one should be provided. 

IF feature NG1 .SC.28 (FP type 4) OR NG1 .SC.29 (FP type 5) THEN ELSE \. Either NG1 .SC.30 or 

NG1 .SC.31 may be provided, but not both at the same time. 
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NOTE 1 
NOTE 2 
NOTES 



Feature NG1-SC.11 (type 1b) shall become "I" for PP instead of "C702" after 31 -December-2009. 
Feature NG1-SC.14 (type 2a) shall become "I" for PP instead of "C703" after 31 -December-2009. 
The transition dates given in notes 1 and 2 are linked to the product development and test dates, (based 
on corresponding ETSI test specification EN 300 176-2 [10]). Example for note 1 : For PPs developed and 
tested before 31 -December-2009, the feature NG1 .SC1 1 is C702. For PPs developed and tested after 
31 -December-2009, this feature is I. 



NOTE 1: Testing specification for audio features, including handsfree, is provided in EN 300 176-2 [10]. 

NOTE 2: PP types Ic, Id, 2b and 2c are based on HATS methodology. This methodology provides objective test 
results more consistent with subjective tests compared to artificial ear methodology. 

NOTE 3: PP type 2a may produce echo issues in combination with VoIP or long delay networks. Types 2b or 2c 
are recommended for this scenario. 



6.9 Application features 



"New Generation DECT; part 3: Extended wideband speech services" devices shall support the following Application 
features. 

Table 8: Application features status 



Feature supported 




Status 1 


Item no. 


Name of feature 


Reference 


PT 


FT 1 


R/B 


P 


NG1.A.1 


Easy PIN-code registration 


5.7 


M 


N/A 


N/A 


NG1.A.2 


Easy pairing registration 


5.7 


M 





N/A 


NG1.A.3 


Handset locator 


5.7 


M 








GAP.A.1 


AC bitstring mapping 


4.2 [12] 


M 


C801 


M 


GAP.A.2 


Multiple subscription registration 


4.2 [12] 


M 


N/A 


N/A 


GAP.A.3 


Manual entry of the PARK 


4.2 [12] 





N/A 


N/A 


GAP.A.4 


Terminal identity number assignment in mono cell system 


4.2 [12] 


M 


M 


N/A 


C801 : IF feature GAP.N.9 OR GAP.N.10 OR GAP.N.12 OR GAP.N.26 THEN M ELSE N/A. 
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6.1 Network (NWK) feature to procedure mapping 

The NWK features to procedure mapping of EN 300 444 [12] (GAP), clause 6.7 with the following changes and 
additional features shall apply. 

Table 9: NWK feature to procedure mapping 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.N.1 Codec Negotiation 




5.2 [21] 


M 


M 


M 


Exchange of codec list during registration 
and location registration 


7.3.1 [21] 


M 


M 


M 


Basic service wideband speech and 
default attributes 


7.3.2 [21] 


M 


M 


M 


Codec Negotiation during call 
establishment 


7.3.3 [21] 


M 


M 


M 


NG1 .N.2 Codec Switching 




5.2 [211 


M 


M 


M 


Codec Change 


7.3.4 [21] 


M 


M 


M 


Slot type modification 


7.3.5(21] 


M 


M 


M 


IVIAC layer advanced connection slot type 
modification 


7.6.5 [21] 








MAC layer connection type modification: 
basic to/from advanced 


7.6.6 [21] 


M 


M 


M 


NG1.N.3 Missed call notification 




5.2 


M 


M 


M 


Generic events notification, general 


7.4.1.1 


M 


M 


M 


Missed call notification 


7.4.1.2 


M 


M 


M 


NG1 .N.4 Voice message waiting 
notification 




5.2 


M 


M 


M 


Generic events notification, general 


7.4.1.1 


M 


M 


M 


Voice message waiting notification 


7.4.1.3 


M 


M 


M 


NG1.N.5 Date and Time 
synchronization 




5.2 


M 


M 


M 


Date and Time synchronization 


7.4.2 


M 


M 


M 


NG1.N.6 Parallel Calls 




5.2 


M 


M 





Parallel call common requirements 


7.4.3.1 


M 


M 


M 


Control messages 


7.4.3.2 


M 


M 


M 


Sending Keypad information 


8.10 [12] 


M 


M 


M 


Codec change for parallel calls 


7.4.3.3 


M 


M 


M 


Sending negative acknowledgement 


7.4.3.4 


M 


M 


M 


Busy system or line notification 


7.4.8.3 


M 


M 


M 


NG1 .N.7 Common parallel call 
procedures (external or internal) 




5.2 


M 


M 





Outgoing parallel call initiation (external 
or internal) 


7.4.3.5.1 


M 


M 


M 


Call waiting indication (external or 
internal) 


7.4.3.5.2 


M 


M 


M 


Call toggle (external or internal) 


7.4.3.5.3 


M 


M 


M 


Call release and call release rejection 


7.4.3.5.4 


M 


M 


M 


On-hold call release 


7.4.3.5.5 


C901 


M 


M 


Call waiting acceptation (from PP to FP) 


7.4.3.5.6 


M 


M 


M 


Call waiting rejection (from PP to FP) 


7.4.3.5.7 


M 


M 


M 


Putting a call on-hold 


7.4.3.5.8 





M 


M 


Resuming a call put on-hold 


7.4.3.5.9 





M 


M 


CLIP on call waiting indication 


7.4.3.5.10 


M 


M 


M 


CNIP on call waiting indication 


7.4.3.5.11 


M 


M 


M 


NG1 .N.8 Call transfer (external or 
internal) 




5.2 


M 


M 





Announced call transfer 


7.4.3.6.1 


M 


M 


M 


Unannounced call transfer 


7.4.3.6.2 


M 


M 


M 


Call re-injection to the line (external or 
internal) 


7.4.3.6.3 


M 


M 


M 


Remote party CLIP on call transfer 


7.4.3.6.4 


M 


M 


M 


Remote party CNIP on call transfer 


7.4.3.6.5 


M 


M 


M 


NG1 .N.9 3-party conference call 
(external or internal) 




5.2 











3-party Conference with established 
internal and external calls 


7.4.3.7 


M 


M 


M 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.N.10 Intrusion call 




5.2 











Implicit call intrusion into a line in "single 
call" mode 


7.4.3.8.1 


M 


M 


M 


Explicit call intrusion (from PR to FP) 


7.4.3.8.2 


M 


M 


M 


NG1.N.11 Call deflection (internal 
or external) 




5.2 











Call deflection (internal) 


7.4.4.2 


M 


M 


M 


Call deflection (external) 


7.4.4.2 


M 


M 


M 


Call deflection control messages 


7.4.4.1.1 


M 


M 


M 


NG1.N.12 Line identification 




5.2 





M 


M 


Line identification general requirements 


7.4.5.1 


M 


M 


M 


General line identification requirements 
for external outgoing calls 


7.4.5.2.1 


M 


M 


M 


Line identification for a first external 
outgoing call using «CALL-INFO» IE 


7.4.5.2.2 


M 


M 


M 


Line identification for a first external 
outgoing call using «MULTi-KEYPAD» 
IE 


7.4.5.2.3 





M 


M 


FP managed line selection for a first 
external outgoing call 


7.4.5.2.4 





M 


M 


General line identification requirements 
for external incoming calls 


7.4.5.3.1 


M 


M 


M 


Line identification for a first external 
incoming call 


7.4.5.3.2 


M 


M 


M 


Line specification in events notification 


7.4.5.4 





M 





NG1.N.13 Call identification 




5.2 





M 


M 


Call identifier general requirements 


7.4.6.1 


M 


M 


M 


Call identifier assignment on outgoing call 
(FPtoPP) 


7.4.6.2 


M 


M 


M 


Call identifier assignment on incoming 
call (FPtoPP) 


7.4.6.3 


M 


M 


M 


NG1.N.14 Multiple lines 




5.2 











Multiple lines common requirements 


7.4.7.1 


M 


M 


M 


Terminal attachment and line settings 


7.4.7.2 


M 


M 


M 


Incoming and outgoing external calls on a 
multiple line system 


7.4.7.3 


M 


M 


M 


Internal calls in multiple line context 


7.4.7.4 


M 


M 


M 


Compatibility with non multiple line PP or 
FP 


7.4.7.5 


M 


M 


M 


NG1.N.15 Multiple calls 




5.2 


M 








Multiple calls general requirements 


7.4.8.1 


M 


M 


M 


Incoming and outgoing external calls on a 
multiple call line 


7.4.8.2 


M 


M 


M 


Busy system or line notification 


7.4.8.3 


M 


M 


M 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1 .N.1 6 List access service 




5.2 


M 


M 





General considerations 


7.4.10.1 


M 


M 


M 


List change notification 


7.4.10.2 





M 


M 


Start / end session 


7.4.10.4.1 


M 


M 


M 


Query supported entry fields 


7.4.10.4.2 





M 


M 


Read entries 


7.4.10.4.3 


M 


M 


M 


Edit entry 


7.4.10.4.4 





M 


M 


Save entry 


7.4.10.4.5 





M 


M 


Delete entry 


7.4.10.4.6 





M 





Delete list 


7.4.10.4.7 











Search entries 


7.4.10.4.8 











Negative acknowledgement 


7.4.10.4.9 


M 


M 


M 


Data packet / Last data packet 


7.4.10.4.10 


M 


M 


M 


DECT system and line settings 
considerations 


7.4.11.1 


M 


M 





Interactions between registration, 
attachment of handsets and lists 


7.4.11.2 


M 


M 





Fields description 


7.4.10.5.1 


M 


M 


M 


[Supported lists] 










Supported list query 


7.4.10.5.2 





M 


M 


IVIissed calls list 


7.4.10.5.3 


M 


M 


M 


Outgoing calls list 


7.4.10.5.4 











Incoming accepted calls list 


7.4.10.5.5 











All calls list 


7.4.10.5.6 











Contact list 


7.4.10.5.7 











Internal names list 


7.4.10.5.8 


M 


M 


M 


DECT system settings list 


7.4.11.3 


M 


M 





Line settings list 


7.4.11.4 


M 


M 





Virtual contact list and call list per line 


7.4.11.5 


C902 


C902 





[Supported DECT system settings] 










PIN code 


7.4.11.3.1 











Clock master 


7.4.11.3.2 


M 


M 





Base reset 


7.4.11.3.3 


M 


M 





FP IP address /type 


7.4.11.3.4 











FP IP address / value 


7.4.11.3.5 











FP IP address / subnet mask 


7.4.11.3.6 











FP IP address / gateway 


7.4.11.3.7 











FP IP address / DNS server 


7.4.11.3.8 











FP version / Firmware version 


7.4.11.3.9 


M 


M 





FP version / EEprom version 


7.4.11.3.10 











FP version / Hardware version 


7.4.11.3.11 











[Supported line settings] 










Line name 


7.4.11.4.1 


M 


M 





Line id 


7.4.11.4.2 


M 


M 





Attached handsets 


7.4.11.4.3 


M 


M 





Dialling prefix 


7.4.11.4.4 











FP melody 


7.4.11.4.5 











FP volume 


7.4.11.4.6 











Blocked number 


7.4.11.4.7 











Multiple calls mode (single/multiple) 


7.4.11.4.8 


C903 


C903 


C903 


Intrusion call 


7.4.11.4.9 











Permanent CLIR 


7.4.11.4.10 


C904 


C904 


C904 


Call forwarding 


7.4.11.4.11 











NG1.N.17 Calling line identity 
restriction 




5.2 











Considerations 


7.4.12.1 


M 


M 





Permanent CLIR mode (all calls) 


7.4.12.2 


M 


M 





Temporary CLIR mode (call by call) 


7.4.12.3 


M 


N/A 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


GAP. N. 11 Location registration 




4.1 [12] 


M 





M 


Location registration 


8.28 [12] 


M 


M 


M 


Location update 


8.29 [12] 


M 








Terminal Capability indication 


7.4.9.1 


M 


M 


M 


GAP.N.14 Service class 
indication/assignment 




4.1 [12] 


M 





M 


Obtaining access rights 


8.30 [12] 


M 


M 


M 


Terminal Capability indication 


7.4.9.1 


M 


M 


M 


Authentication of PT 


8.24 [12] 


M 


M 


M 


GAP.N.16ZAP 




4.1 [12] 


M 








Obtaining access rights 


8.30 [12] 


M 


M 


M 


Terminal Capability indication 


8.17 [12] 


M 


M 


M 


Incrementing the ZAP value 


8.26 [12] 


M 


M 


M 


Terminal Capability indication 


7.4.9.1 


M 


M 


M 


GAP. N.I 8 Subscription 
registration user procedure on-air 




4.1 [12] 


M 


M 


M 


Obtaining access rights 


8.30 [12] 


M 


M 


M 


Terminal Capability indication 


7.4.9.1 


M 


M 


M 


GAP. N.I 9 Linl< control 




4.1 [12] 


M 


M 


M 


Indirect FT initiated link establishment 


7.3.8 [21] 


M 


M 


M 


Direct PT initiated link establishment 


8.36 [12] 


M 


M 


M 


Link release "normal" 


8.37 [12] 


M 


M 


M 


Link release "abnormal" 


8.38 [12] 


M 


M 


M 


Link release "maintain" 


8.39 [12] 


M 


M 


M 


GAP. N. 24 Signalling of display 
characters 




4.1 [12] 











Display 


8.16 [12] 


M 


M 


M 


Terminal capability indication 


7.4.9.1 


M 


M 


M 


GAP.N.25 Display control 
characters 




4.1 [12] 











Display 


8.16 [12] 


M 


M 


M 


Terminal capability indication 


7.4.9.1 


M 


M 


M 


GAP.N.31 Internal Call 




4.1 [12] 


M 


M 


M 


Internal call setup 


7.3.6 [21] 


M 


M 


M 


Internal call keypad 


8.19 [12] 


M 








Internal call CLIP 


8.43 [12] 


M 


M 


M 


Internal call CNIP 


8.44 [12] 


M 


M 


M 


Internal call codec priority 


7.4.3.9 


M 


M 


M 


C901 : IF NG1 .N.13 THEN "0" ELSE "M". 
C902: IF NG1.N.14 THEN "0" ELSE"!". 
C903: IF NG1.N.15 THEN "M" ELSE"!". 
C904: IFNG1.N.17 THEN 'M' ELSE"!". 
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6.1 1 Data Link Control (DLC) Service to procedure mapping 

The DLC service to procedure mapping of EN 300 444 [12] (GAP), clause 6.8.1, with the following changes and 
additional services shall apply. 

Table 10: DLC service to procedure mapping 



Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.D.1 LU1 Transparent 
Unprotected service (TRUP) 
Class 0/minimum_delay 




5.3 [12] 


M 


M 


M 


LU1 Transparent Unprotected service 
(TRUP) operation 


11.2 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


IVIinimum delay (speech) operation 


14.2.3 [4] 


M 


M 


M 


LLIVIE U-plane establishment 


9.9.1 [12] 


M 


M 


M 


NG1.D.2 LU1 Transparent 
Unprotected service (TRUP) 
Class 




5.3 [21] 


C401 


C401 


C401 


LU1 Transparent Unprotected service 
(TRUP) operation 


11.2 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLME U-plane establishment 


9.9.1 [12] 


M 


M 


M 


NG1 .D.3 LU7 64 kbit/s protected 
bearer service 




5.3 [21] 


C401 


C401 


C401 


LU7 DLC layer service 


1 1 .9.4 [4] 


M 


M 


M 


NG1.D.4 LU12 LU 12 Unprotected 
Framed service (UNF) Class 




5.3 [12] 


C401 


C401 


C401 


LU12 UNprotected Framed service (UNF) 
operation 


11.14 [4] 


M 


M 


M 


Class 0: No Lux retransmission or 
sequencing 


14.2.3.1 [4] 


M 


M 


M 


Class procedures 


14.3.2 [4] 


M 


M 


M 


LLIVIE U-plane establishment 


9.9.1 [12] 


M 


M 


M 


NG1.D.5FU1 DLC frame 




5.3 [12] 


M 


M 


M 


FU1 frame operation 


8.19 [12] 


M 


M 


M 


FU1 frame structure 


1 2.2 [4] 


M 


M 


M 


NG1.D.6FU7 DLC frame 




5.3 [12] 


C401 


C401 


C401 


FU7 frame structure 


11.9.4.2 [4] 


M 


M 


M 


NG1.D.7FU12 DLC frame with 
adaptation for codec G. 729.1 




5.3 [12] 


C401 


C401 


C401 


FU12 frame structure 


12.12 [4] 


M 


M 


M 


Annex for codec G. 729.1 


E.I [4] 


M 


M 


M 


FU12frame operation 


7.5.2 [12] 


M 


M 


M 
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6.12 Medium Access Control (MAC) service to procedure 
mapping 

The MAC service to procedure mapping of EN 300 444 (GAP) [12], clause 6.8.2, with the following changes and 
additional services shall apply. 

Table 11 : MAC service to procedure mapping 



Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1M.1 lN_minimum delay 
symmetric MAC service type 




5.4 [21] 


M 


M 


M 


MAC layer procedures: general 


7.9.1 [21] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lN_minimum delay symmetric MAC service, 
type 1 


5.6.2.1 [3] 


M 


M 


M 


NG1.M.2 lN_normal delay 
symmetric MAC service type 




5.4 [21] 











MAC layer procedures: general 


7.9.1 [21] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lN_normal delay symmetric MAC service 
type 2 


5.6.2.1 [3] 


M 


M 


M 


NG1.M.3 lpQ_error_detection 
symmetric MAC service type 




5.4 [21] 











MAC layer procedures: general 


7.9.1 [21] 


M 


M 


M 


MAC Connection oriented service 


5.6 [3] 


M 


M 


M 


MAC Basic connection 


5.6.1.1 [3] 


M 


M 


M 


MAC Advanced connection 


5.6.1.2 [3] 


M 


M 


M 


lp_error_detection symmetric MAC service 
types 


5.6.2.1 [3] 


M 


M 


M 


Single-subfield protected format 


6.2.1.3.4 [3] 


M 


M 


M 
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Service/Procedure mapping 




Status 1 


Service 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1 .M.4 Advanced connections 




5.4 [21] 


M 


M 


M 


Setup of advanced connection, bearer 
setup (A-field) 


7.6.5 [21] 


M 


M 


M 


Connection type modification: basic to/from 
advanced 


7.6.6 [21] 


M 


M 


M 


Slot type modification 


7.6.7(21] 


M 


M 


M 


Service type modification 


7.6.8 [21] 


C1101 


C1101 


C1101 


ECN number modification 


7.6.9 [21] 


C1 102 


C1 102 


C1 102 


Connection/bearer release 


7.6.10 [21] 


M 


M 


M 


NG1 .M.5 "no-emision" mode 




5.4 











Tail identification for "no emission" mode 


7.1.2 [3] 


M 


M 


M 


Extended Physical and IVIac layer 
capabilities (part 2) bit a23 


7.2.3.11 [3] 


M 


M 


M 


Bearer handover/replacement information, 
multiframe-countdown 


7.2.4.3 [3] 


M 


M 


M 


"no emission" mode sync information 


7.3.5.3 [3] 


M 


M 


M 


"no emission" mode procedures 


9.4 [3] 


M 


M 


M 


IVIanagement procedures for "no emission" 
mode 


11.11 [3] 


M 


M 


M 


GAP.M.2 Continuous broadcast 




5.2 [12] 


M 


M 


M 


Downlink broadcast 


7.6.3 


M 


M 


M 


Higher Layer information FP broadcast 


7.4.9.2 


M 


M 


M 


GAP.IVI.3 Paging broadcast 




5.2 [12] 


M 


M 


M 


Paging broadcast 


7.6.4 [21] 


M 


M 


M 












GAP.IVI.9 Bearer handover, intra- 
cell 




5.2 [12] 


M 


C502 


C502 


Bearer handover request 


7.6.11 [21] 


M 


M 


M 


GAP.IVI.10 Bearer handover, 
inter-cell 




5.2 [12] 


M 








Bearer handover request 


7.6.11 [21] 


M 


M 


M 


GAP.I\/1.11 Connection handover, 
intra-cell 




5.2 [12] 


M 


C503 


C503 


Connection handover request 


7.6.12 [21] 


M 


M 


M 


GAP.1\/I.12 Connection handover, 
inter-cell 




5.2 [12] 


M 








Connection handover request 


7.6.12 [21] 


M 


M 


M 


GAP.M.13 SARI support 




5.2 [12] 


M 








Downlink broadcast 


7.6.3 


M 


M 


M 


Higher Layer information FP broadcast 


7.4.9.2 


M 


M 


M 


C502: IF service GAP.M.1 1 THEN ELSE M. 

C503: IF service GAP.M.9 THEN ELSE M. 

C1 101 : IF service NG1 .4 OR NG1 .5 OR NG1 .6 OR NG1 .2 lA II OR NG1 .2 lA III THEN M ELSE 0. 

C1 102: IF multiple connection between the same PT-FT pair THEN IVI ELSE 
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6.13 Application feature to procedure mapping 

The Application feature to procedure mapping of EN 300 444 [12] (GAP), clause 6.8.3, with the following changes 
shall apply. 

Table 12: Application feature to procedure mapping 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 


R/B 


P 


NG1.A.1 Easy PIN code 
registration 




5.7 


M 


N/A 


N/A 


Registration mode automatic access 


7.10.1.3.1 


M 


N/A 


N/A 


Searching mode and PIN code requests 


7.10.1.1.1 


M 


N/A 


N/A 


Base station name selection 


7.10.1.3.2 








N/A 


Registration user feedback 


7.10.1.3.3 


M 





N/A 


NG1.A.2 Easy pairing registration 




5.7 


M 





N/A 


Easy pairing description 


7.10.1.2.1 


M 


M 


N/A 


Registration mode automatic access 


7.10.1.3.1 


M 


N/A 


N/A 


Base station limited registration mode 


7.10.1.2.2 


N/A 


M 


N/A 


Searching mode request 


7.10.1.2.3 


M 


N/A 


N/A 


Base station name selection 


7.10.1.3.2 








N/A 


Registration user feedback 


7.10.1.3.3 


M 





N/A 


NG1.A.3 Handset locator 




5.7 


M 








Handset locator 


7.10.2 


M 


M 





GAP.A.1 AC to bitstring mapping 




4.2 [12] 


M 


C801 


M 


AG to bitstring mapping 


14.2 [12] 


M 


M 


M 


GAP. A. 2 IVIultiple subscription 
registration 




4.2(12] 


M 


N/A 


N/A 


Subscription control 


14.1 [12] 


M 


N/A 


N/A 


GAP.A.3 Manual entry of the 
PARK 




4.2(12] 





N/A 


N/A 


Manual entry of the PARK 


14.3 [12] 


M 


N/A 


N/A 


GAP. A. 4 Terminal identity number 
assignment in mono cell system 




4.2(12] 


M 


M 


N/A 


Terminal identity number assignment 


14.4 [12] 


M 


M 


N/A 


G801 : IF feature GAP.N.9 OR 


GAP.N.10 OR GAP.N.12 OR GAP.N.26 Th 


lEN M ELSE 


N/A. 







6.14 General requirements 

6.1 4.1 Network (NWK) layer message contents 

The requirements of TS 102 527-1 [21], clause 6.14.1 shall apply. 

6.14.2 Transaction identifier 

The requirements of TS 102 527-1 [21], clause 6.14.2 shall apply. 

6.1 4.3 Length of a Network (NWK) layer message 

The requirements of TS 102 527-1 [21], clause 6.14.3 shall apply. 

6.1 4.4 Handling of error and exception conditions 

The requirements of TS 102 527-1 [21], clause 6.14.4 shall apply. 

6.1 4.5 Generic Access Profile (GAP) default setup attributes 

The requirements of TS 102 527-1 [21], clause 6.14.5 shall apply. 
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6.14.6 Coexistence of Mobility Management (MM) and Call Control (CC) 
procedures 

The requirements of TS 102 527-1 [21], clause 6.14.6 shall apply. 

6.1 4.7 Coding rules for information elements 

The requirements of TS 102 527-1 [21], clause 6.14.7 shall apply. 

7 Procedure description 

The following clauses define the process mandatory procedures which are in the scope of the New Generation DECT 
wideband speech. Each procedure (if appropriate) is divided into three parts: 

a) normal (i.e. successful) case(s). This part defines the functions and respective protocol element values in 
normal operation; 

b) associated procedure(s). This is an integral part of the actual procedure (if defined in the present document), 
i.e. if a procedure is being declared to be supported, the respective entity shall also support the associated 
procedures, e.g. timer management, in the clause following the description of the normal case; 

c) exceptional case(s). This is an integral part of the actual procedure (if defined in the present document), i.e. if a 
procedure is being declared to be supported, the respective entity shall also support the exception handling 
defined in the clause following the description of the normal case. 

All protocol elements listed in the following clauses are process mandatory, i.e. the FT and PT depending on their role 
in the procedure shall send or shall receive and process the relevant protocol elements as listed in the respective tables if 
not explicitly stated as being optional. 

The primitives used in procedure descriptions are defined only for the purpose of describing layer-to-layer interactions. 
The primitives are defined as an abstract list of parameters, and their concrete realization may vary between 
implementations. No formal testing of primitives is intended. The primitive definitions have no normative significance. 

7.1 Backward compatibility with Generic Access Profile (GAP) 
and with New Generation DECT part 1 (wideband speech) 
equipment 

7.1 .1 Backward compatibility with Generic Access Profile (GAP); 
Requirements for NG-DECT, part 3 Fixed Parts (FPs) 

The FP shall support the GAP (EN 300 444 [12]) standard procedures (full slot and ITU-T Recommendation 
G.726 [15]). In other words, it shall inter-operate with a GAP compliant PP. 

NOTE 1 : The FP may detect the type of PP by means of the Information Element <Terminal Capability> provided 
at registration. 

NOTE 2: It should be noted that GAP compliant PPs may have a more relaxed requirement of TCLw than New 
Generation DECT part 3 devices. In some scenarios, when combining GAP terminals with poor TCLw 
with long delay networks (like VoIP) and insufficient echo cancellation in the network , audible echo 
could be perceived by the far end terminal. This problem is not specific of devices compliant with the 
present document. For more information refer to EN 300 175-8 [8], annex E. 
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7.1 .2 Backward compatibility witin Generic Access Profile (GAP); 
Requirements for NG-DECT, part 3 Portable Parts (PPs) registered 
on GAP compliant FPs 

The PP shall use the GAP standard procedures (full slot and ITU-T Recommendation G.726 [15]) in front of GAP 
standard FP. 

7.1 .3 Backward compatibility with New Generation DECT, part 1 ; 
Requirements for NG-DECT, part 3 Fixed Parts (FPs) 

The FP shall support DECT New Generation part 1 (TS 102 527-1 [21]) procedures. In other words, a DECT New 
Generation, part 3 Fixed part shall become exactly as a DECT New Generation, part 1 FP for a New Generation Part 1 
PP. All features and services defined in TS 102 527-1 [21] shall be provided. 

NOTE 1 : The FP may detect the type of PP by means of the Information Element <Terminal Capability> provided 
at registration. 

NOTE 2: It should be noted that New Generation DECT part 1 PPs may have a more relaxed requirement of TCLw 
than New Generation DECT part 3 devices. Note 2 of clause 7.1.1 may be also applicable this case. For 
more information refer to EN 300 175-8 [8], annex E. 

7.1 .4 Backward compatibility with New Generation DECT, part 1 ; 
Requirements for NG-DECT, part 3 Portable Parts (PPs) registered 
on NG-DECT part 1 FPs 

The PP shall use the part 1 standard procedures (TS 102 527-1 [21]) in front of NG-DECT part 1 FPs. 

7.2 Generic Access Profile (GAP) procedures 

Unless otherwise noted, all procedures defined in EN 300 444 [12] GAP are automatically applicable to New 
Generation DECT wideband speech. Therefore the present document can be considered an extension of GAP. 

7.3 New Generation DECT; part 1 : Wideband Speech 
procedures 

The present document is defined as an extension of New Generation DECT; part 1: Wideband Speech [21]. 

Unless otherwise noted, all procedures defined in TS 102 527-1 [21] (New Generation DECT; part 1: Wideband 
Speech) are automatically applicable to New Generation DECT; part 3: Extended Wideband Speech Services. 

The clauses 7.4 to 7.10 describe the additional procedures specific for New Generation DECT; part 3: Extended 
wideband speech services. 

7.3.1 Implementation examples of part 1 : Wideband Speech specific 
procedures 

For detailed examples of Wideband speech specific procedures, please refer to the informative annex D of 
TS 102 527-1 [21]. 

7.4 Network (NWK) layer procedures specific for part 3 

This clause specifies the additional NWK layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 
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This profile does not prevent any PT or FT fi-om transmitting or receiving and processing any other NWK layer 
message or information element not specified in the profile. A PT or FT receiving an unsupported NWK layer message 
or information element, which it does not recognize, shall ignore it, as specified in EN 300 175-5 [5], clause 17. 

7.4.1 Generic events notification 



7.4.1.1 



General 



Equipment supporting New Generation DECT wideband voice shall support the generic events notifications as 
described in this clause. 

If there is no existing connection when sending an events notification, the CLSS procedure shall be used as defined in 
clause 10.4.2.3 of EN 300 175-5 [5] with the «Event notifications» information element in the {FACILITY} 
message. 

FP shall use an already established link for the purpose of transmitting the {FACILITY} message containing the 
«Events Notification» information element to the PP. If link is not available, the FP shall initiate indirect link 
establishment. Direct FP initiated link establishment is out of the scope of the present document. The following 
requirements apply for the FP and the PP: 

• The FP shall send the "Event type" and "Event sub type" argument to indicate the kind of event. 

• The PP shall support the "Event multiplicity" argument which should be used to indicate how many 
unconsulted events of the specific type are waiting, regardless of any previous notification. The PP shall be 
capable of handling values up to 127. The PP shall ignore events of unknown types or sub-types. 

• It is the responsibility of the FP to ensure that Event status information within the PP is up to date. 

Optionally more than one event notification can be included by using the extension bit. 

Whatever the FACILITY transport mode (CLSS procedure or re-use of already established link), the FACILITY 
message shall be used with dummy transaction identifier value 6 and the protocol discriminator CISS. 

The notification shall be consistent with the procedure "Line specification in events notification" defined in 
clause 7.4.5.4. If this procedure is implemented, the notification shall include the «CALL-INFORMATION» 
information element with the line identifier (even if one line only is implemented in the DECT system). 

Table 13: Values used within {FACILITY} message to convey Lineld in notification 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Call information» 








<ldentifier type> 





Line identifier 


<ldentifier subtype> 


3 


Relating-to line identifier 


<ldentifier value> 


All 


The line identifier value itself 



Notification of an event shall be sent only to relevant PPs. 

If notification is related to a line : the notification shall be sent to registered PPs that are attached to this line. The FP 
shall use the "Attached handsets" line setting to determine these PPs. For example this is the case for the voice message 
waiting notification, the missed calls notification and the internal names list change notification. 

NOTE 1: A PP may be attached to several lines. 

NOTE 2: Exception case: the current procedure is still valid in case the notification concerns several lines of the 
DECT system. In this case Call information IE may include several line ids or may be set to "All lines". 
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7.4.1.2 



Voice Message waiting notification 



Upon reception of a voice message waiting indication (MWI) from the network on a dedicated line, the FP shall send to 
any PP attached to this line, a voice message waiting notification using the generic events notification. 

NOTE: The FP is aware of the attached handsets to a line thanks to the line settings list/attached handsets field. 

«Events notification» information element shall be filled with the values specified in table 14. 

Table 14: Values used within {FACILITY} message for voice message waiting indication activation 



Information element 


Field within the Information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 








<Event type> 


1 


IVIessage waiting 


<Event sub type> 


1 


Voice 


<Event multiplicity > 


1..127 


Number of messages 



Upon reception of a { FACILITY } message with a content as defined in table 14, the PP shall activate the Voice MWI 
status to the receiving user. 

Voice message waiting deactivation (i.e. when voice mail box was consulted) shall be achieved in a similar way to 
activation except that <Event multiplicity > argument is set to zero. 



7.4.1.3 



Missed call notification 



When an incoming call is not answered on any PP attached to a line, the FP shall send to each PP attached to this line a 
missed call notification. 

If the list change notification procedure is implemented for missed call list in the FP, FP shall send the list change 
notification concerning the missed calls list in the same generic events notification. 

« Events notification » information element shall be filled with the values given in table 15. 

Table 15: Values used within { FACILITY } message for missed call notification 



Information element 


Field within the Information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 








<Event type> 


2 


Missed call 


<Event sub type> 


1 


Voice 


<Event multiplicity > 


1...127 


Number of missed call 


<Event type> 


3 


List change indication 


<Event sub type> 


1 


IVIissed calls list 


<Event multiplicity > 


All 


Total number of elements in the list 



Upon reception of a { FACILITY } message with a content as defined in table 15, the PP shall indicate the missed call 
to the receiving user. The PP may use the previous calling party information provided with the last incoming call 
presentation. 

After user intervention the PP shall access the missed call list via the list access "Read entries" command (see 
clause 7.4.10.4.3.1) feature. 

The FP shall then send a Missed call deactivation notification (i.e. when call log was consulted). This shall be achieved 
in a similar way to activation except that <Event multiplicity> argument is set to zero. 

7.4.1 .4 List change notification 

See "List access service", list change notification procedure (clause 7.4.10.2) for the detailed behaviour. 
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7.4.2 Date and Time synchronization 



Equipment supporting New Generation DECT wideband voice shall support the "Date and Time synchronization" 
feature as described in the present clause. 

The DECT entity shall use an already established link for the purpose of transmitting the {FACILITY} message 
containing the «Time-Date» information element to the peer entity. It is the responsibility of the entity to ensure that 
time and date information within the peer entity is up to date. 

If there is no existing connection when sending the FACILITY message, the CLSS procedure may be used as defined in 
clause 10.4.2.3 of EN 300 175-5 [5] with the «TimeDate» information element in the {FACILITY} message. 

Whatever the FACILITY transport mode (CLSS procedure or re-use of already established link), the FACILITY 
message shall be used with dummy transaction identifier value 6 and the protocol discriminator CISS. 

For the values used in « TIME-DATE » information element see table 16. 

Table 16: Values used within { FACILITY } message for date and time synchronization 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Time-Date» 










<Coding> 


11B 


1 1 Time and Date 




<lnterpretation> 





The current time/date 




<Time/date > 


All 





Upon reception of a { FACILITY } message with a content as defined in table 16, the peer entity shall set its time and 
date information to the received one. The date and time on FP side is called "DECT system date and time" in the 
following text. 

The FP and PP shall both support the "FT initiated Date and Time synchronization" procedure of clause 7.4.2.1, for 
synchronizing all PPs with the DECT system date and time. 

The PP should support and the FP shall support the "PT initiated Date and Time synchronization" procedure of 
clause 7.4.2.2. If used by the PP, the FP should not use clause 7.4.2.1 at the same time with the same PP especially 
when using the date and time from the network. 

The present procedure (clause 7.4.2) shall be consistent with the "Clock master" setting (see clause 7.4. 1 1 .3.2) of the 
DECT system settings list (clause 7.4.11.3), if implemented ("List access service", feature NG1.N.16). When the setting 
is implemented: 

• If the "Clock master" field is equal to "FP", PPs shall not use the "PT initiated Date and Time synchronization" 
procedure. The FP may set the DECT system date and time as received from the network (e.g. received upon 
network incoming call, or through NTP), or from a dedicated interface (e.g. local or web interface). 

• If the "Clock master" field is equal to "PP": a PP shall be able to define the DECT system date and time on the 
FP, using procedure "PT initiated Date and Time synchronization" of clause 7.4.2.2. The FP shall ignore any 
date and time received by any other means (e.g. received from the network). 

In both cases, the FP shall use procedure "FT initiated Date and Time synchronization" of clause 7.4.2.1 to update the 
date and time of all (other) registered handsets. 



7.4.2.1 



FT initiated Date and Time synchronization 



The present procedure shall be used by the FP in order to update the PP date and time and synchronize it with the DECT 
system date and time. The DECT system date and time could have been provided by the network, or by one of the PPs 
using procedure "PT initiated Date and Time synchronization" of clause 7.4.2.2. 

NOTE: When the the "Clock master" setting is implemented, the DECT system date and time origin is restricted. 
However a PP should never ignore the FP notification, even if the "Clock master" field is set to PP, 
because the DECT system date and time may have been set by another PP. 
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PP 



FP 



FACILITY 



« TIME-DATE » 



7.4.2.2 



Figure 1 : FT initiated Date and time synchronization 



PT initiated Date and Time synchronization 



In some cases (e.g. if the date and time are not provided by the network or erroneous), the DECT system date and time 
may be provided by one of the PPs, using the present procedure. 

When the the "Clock master" field is equal to "PP", the DECT system date and time shall only be provided by one of 
the PPs using the present procedure. However, procedure "FT initiated Date and Time synchronization" of 
clause 7.4.2. 1 may be used subsequently, in order to transfer the updated date and time to all other registered PPs. 



PP 



FP 



FACILITY 



: TIME-DATE : 



Figure 2: PT initiated Date and time synchronization 



7.4.3 Handling of parallel calls 



7.4.3.1 



Parallel call common requirements 



Procedures in clause 7.4.3 apply to DECT systems allowing to handle several simultaneous calls, and offer a common 
handling of them in various situations (PSTN double calls, VoIP multiple calls on a single line, as well as parallel call 
situations occurring in a multiple line DECT system). Clause 7.4.3 also includes related procedures (for "Call transfer", 
"Call intrusion" and "3-party conference with established internal and/or external calls"). 

The "Parallel call" feature is a prerequisite feature including high level procedures and requirements. Clauses "Common 
parallel call procedures", "Call transfer", "Call intrusion" and "3-party conference with established internal and/or 
external calls", are all handled here because they imply implementation of the "Parallel call" feature, but are however 
handled as separate features. 

In all parallel call scenarios there shall always be only one link between FP and PP, with one U-Plane and one call 
control instance. 
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7.4.3.2 



Control messages 



The following control codes shall be transmitted as keypad information in {CC-INFO} messages and shall trigger the 
corresponding actions in the FP. 

Table 17: Control messages for control of parallel calls 



Procedure 


Control message 


Direction 


PP Status 


Initiating a second call (internal) 


17H + number 
17H (see note 1) 


PP to FP 


M 


Initiating a second call (external) 


15H + number (see note 2) 


PP to FP 


M 


Call waiting indication (external or internal) 


Clip (see note 3) -i- IE «SIGNAL = 'call 
waiting tone' = 07H» 


FP to PP 


M 


Intrusion call request indication (only internal) 


IE «SIGNAL = 'Intercept tone ON' = 
02H» 


FP to PP 





Call toggle request (external or internal) 


1CH31H 


PP to FP 


M 


3-party conference call request (external or 
internal) 


1CH32H 


PP to FP 





Call release (of the indicated call), 

or Active call release (if the PP does not 

implement "Call identification" 


1CH33H 


PP to FP 


M 


Call transfer request (external or internal) 


1CH34H 


PP to FP 


M 


Call waiting acceptation 


1CH35H 


PP to FP 


M 


Call waiting rejection 


1CH36H 


PP to FP 


M 


On-hold call release (when 2 parallel calls are 
established) 


1CH37H 


PP to FP or 
FP to PP 


C1701 


Call release rejection 


IE «SIGNAL, 09H = negative 
acknowledgement tone» 


FP to PP 


M 


Explicit call intrusion 


1CH40H 


PP to FP 





Putting a call on-hold 


1CH41H 


PP to FP 





Resuming a call put on-hold 


1CH42H 


PP to FP 





C1701: IF feature NG1.N.13 THEN "0" ELSE "M". 



NOTE 1 : In case there is no ambiguity (i.e. when there are only two registered PPs switched on), the number can be 
omitted. 

NOTE 2: Use of 31H, 32H, 33H, 35H, etc., as number after 15H may have a specific meaning for the network. For 
backward compatibility reasons, the FP may have to interpret these codes as control messages or send 
them transparently to the network. 

NOTE 3: Numbering plan id field of CLIP IE is set to "private numbering plan" for internal calls, any other type for 
external calls (as specified in TS 102 527-1 [21]). 

NOTE 4: The definition of the new CO-control code IC is proposed for use as described in table 17. 

NOTE 5: The new DECT codes may need a translation into network control messages on FP side. These messages 
are network operator dependent. 

NOTE 6: Network control messages may be sent directly by the user as keypad information. The FP should send 
them transparently to the network. 



7.4.3.3 



Codec change for parallel calls 



In case the parallel calls use different codecs, the standard codec change procedure shall be used (see 
TS 102 527-1 [21], clause 7.3.4 and annex D). 
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PP 



FP 




Call established 




CC-INFO 



« MULTI-KEYPAD, 17H/15H » 
CC-INFO 



« MULTI-KEYPAD, number digits » 
CC-INFO 



« MULTI-KEYPAD, number digits » 



CC-SERVICE-CHANGE 



« CODEC-LIST » 
CC-SERVICE-ACCEPT 



IWU-INFO 



« CODEC-LIST » 
IWU-INFO 



« CODEC-LIST » 



Figure 3: Codec change procedure: example for outgoing call initiation 



7.4.3.4 



Sending negative acknowledgement 



When the FP fails to fulfil a service requested by the PP, the FP shall warn the user by sending the «SIGNAL» 
information element with the value 09H indicating negative acknowledgement tone. 

NOTE 1 : A possible cause of failure may be unsuccessful interaction of the FP with the network. 

NOTE 2: Examples of use of this procedure are the "Call release and call release rejection" (clause 7.4.3.5.4), 
"On-hold call release" (clause 7.4.3.5.5) and "Explicit call intrusion" (clause 7.4.3.8.2) procedures. 

NOTE 3: In the special case where the requested service cannot be fulfilled because it would exceed the DECT 

system or line capacity, the "Busy system or line notification" procedure of clause 7.4.8.3 is used instead. 
The main identified use case is in the context of multiple call lines (clause 7.4.8) but other parallel call 
use cases are relevant (e.g. in the context of a multiple lines DECT system). See also NG1.N.6 in 
clause 6.10. 

7.4.3.5 Common parallel call procedures (external or internal) 

This clause details the procedures of a feature entitled "Common parallel call procedures (external or internal)". This 
feature is a set of common procedures for handling PSTN double calls, VoIP multiple calls on a single line, as well as 
parallel call situations occurring in a multiple line DECT system (and especially for PPs attached to multiple lines in 
such a system). 

These procedures apply to the FP and a PP already involved in at least one call on a line in a DECT system. If the 
"Multiple call" feature is implemented on a line, this line may be configured in "single call" mode, or in "multiple call" 
mode (see clause 3.1). 

Implementation of the "Parallel calls" feature is a pre-requisite on PP and FP sides for implementation of the "Common 
parallel call procedures (external or internal)" feature. 
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Implementation of the "Call Identification" feature and the "Line Identification" feature on the FP side is a prerequisite 
for implementation of the "Common parallel call procedures (external or internal)" feature on a DECT system. 
Conversely, for the PP, the following procedures contain some requirements that are conditional to the implementation 
of these features. 

When implementing the "Common parallel call procedures" feature, the PP shall set the corresponding terminal 
capability bit. The FP shall set bit a3]^ of the "Extended higher layer capabilities (part 2)" (see EN 300 175-5 [5], 

clause F.3). 

NOTE: Implementation of the "Common parallel call procedures" feature is mandatory for NG DECT Part 3 PPs. 
This capability bit is therefore primarily meant for non-NG DECT Part 3 PPs or FPs that would 
implement the feature. 

Implementation of the "Common parallel call procedures" feature is itself a prerequisite for the implementation of the 
"Multiple calls" feature, or of the "Multiple lines" feature on a DECT system. 

7.4.3.5.1 Outgoing parallel call initiation (external or internal) 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

The initiation of an outgoing parallel call shall be done by sending either the internal call (17H) or the register recall 
(15H) keypad information in a « MULTI-KEYPAD » information element in a {CC-INFO} message. In the same or 
other {CC-INFO} message(s), one or more further keypad information containing the decimal coded digits of an 
internal number resp. an external number shall follow. 

However, in case there is no ambiguity (i.e. when there are only two registered PPs switched on), the number can be 
omitted. 
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PP FP 




<;^ Ongoing call (external or internal ^>. 




Outgoing 

parallel call 

invitation 


CC-INFO 




« MULTI-KEYPAD, < Keypad info = '1 5/1 7' H > » 










The FP assigns a call identifier: 




CC-INFO 


« CALL-INFORMATION, 


Ignored if the PP does not implement < id type/subtype = 'Call identifier', 
the "Call identification" feature value = 'assigned call id' > 




» 














If the PP does NOT use FP-managed line selection: 




CC-INhO 


« CALL-INFORMATION, 


Line selected by PP for the call < id type = 'Line identifier', 
using the CALL-INO method subtype = 'external call', 
(external call only) value = 'u' > 

< id type/subtype = 'Call identifier', value = 'assigned call id' > 


OR 


» 


Line selected by PP for the call ^^ MULTI KEYPAD 

using the KEYPAD method ^ keypad info = '23 3u'H > » 

(external call only) 








CC-INFO 






« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION (if PP implements NG1.N.13), 
< id type/subytpe = 'Call identifier', 
value = 'assigned call id' > 
» 





Figure 4: Outgoing parallel call initiation request with line selection by the PP 

Line selection: If the PP implements the "Line identification" procedure and the new call is external, it shall send the 
line identifier for the line it has selected for the new call (see figure 4), unless it uses FP-managed line selection (see 
clause 3.1 and figure 5). 

NOTE 2: Instead of the sequence given above, the PP might also combine 15/17H, line selection and called number 
in two or three messages. In these cases the FP will answer correspondingly in two or more messages. 
See clauses C.3 "Multiple calls diagrams" and C.4 "Parallel call complex or alternative diagrams", for 
more information. 

FP-managed line selection: If FP-managed line selection is used (see figure 5), the FP shall notify back the PP of the 
selected line for the call, regarless of whether the PP implements the "Line identification" feature or not. However, it 
shall not send such a notification to a GAP PP. 

NOTE 3: A PP not implementing the "Line identification" feature (i.e. a PPs compliant with NG-DECT Part 1 
(TS 102 527-1 [21]), GAP (EN 300 444 [12]) and PPs compliant with the present document not 
implementing the feature, or a GAP PP) also implicitly uses FP-managed line selection. 

Busy tone signal: If the line or the FP cannot support the additional call, it shall not send any call information and send 
a busy tone signal instead. 
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PP FP 




•<^^ Ongoing call (external or internal) J^> 






-^ u- 










Outaoinq call initiation with Line selection bv the PP (not FP-manaaed) 


Outgoing 

parallel call 

invitation 


CC-INFO 


« MULTI-KEYPAD, < Keypad info = '15/17'H> » 








Call id assianement bv the FP 


CC-INFO 




« CALL-INFORMATION, 


possibly ignored if PP does not implement < id type/subtype = 'Call identifier', 
the "Call identification" feature value = 'assigned call id' > 




» 




CC-INFO 






« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION (if PP implements NG1.N.13), 
< id type/subtype = 'Call identifier', 
value = 'assigned call id' > 
» 




FP-manaaed line selection 


CC-INFO 




« CALL-INFORMATION, 


Repeated here as a result of the < id type = 'Line identifier', subtype = 'external call', 
CALL-INFO completion principle value = 'u' > 


1 


possibly ignored if PP does not implement < id type/subtype = 'Call identifier', 
the "Call identification" feature value = 'assigned call id' > 


» 





Figure 5: Outgoing parallel call initiation request with FP-managed line selection 

NOTE 4: The line identifier is ignored if the PP does not implement the "Line identification" feature; it is present 
here either as a result of a PP using FP-managed line selection, or-if the PP did select a line for the new 
call-as a result of the "CALL-INFORMATION completeness principle" (see clause 3.1). In case the line 
identifier is not yet available in the FP (e.g. because FP decides about line depending on dial progress), 
the FP might omit the line identifier in the message. 

The FP may change the audio codec for the parallel call by use of the service change procedure (see clause 7.4.3.3, 
"Codec change for parallel calls"). 

In case the parallel call is internal, the FP shall use the GAP "internal call CLIP" and "internal call CNIP" procedures 
for this parallel call (see clause 6.10). 

NOTE 5: In case internal call (17H) is sent, the '*' character can be sent, meaning general internal call. 



7.4.3.5.2 



Call waiting indication (external or internal) 



This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented and used 
on a line, the line may be configured in "single call" mode, or in "multiple call" mode. 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

NOTE 2: In "single call" mode, PPs not involved in a call do not receive the call waiting indication and do not ring. 
In "multiple call" mode, there may be several PPs already involved in a call and all of them receive the 
call waiting indication; idle PPs receive an incoming call request and ring. 
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Call waiting shall be indicated by the FP by sending in a {CC-INFO} message the information element «SIGNAL» 
with the value 07H indicating 'call waiting' tone. Together with this procedure, the FP shall use the "CLIP on call 
waiting" procedure of clause 7.4.3.5.10. 

Furthermore, as a result of the "Call identification" feature, the FP shall assign an identifier for the waiting call, and 
send it in a «CALL-INFORMATION» information element included in every {CC-INFO} message used (one or 
two), regardless of whether the PP implements the "Call identification" feature or not. 

If an internal call is waiting, the information element «Calling Party Number» shall indicate a private numbering 
plan. 



PP 



FP 



Line on which waiting call 
occurred if external (see note 3) 

Ignored if the PP does not implement 
the "Call identification" feature 



CW tone 

heared by 

user 



Line on which waiting call 
occurred if external (see note 4) 

I 

Ignored if the PP does not implement 
the "Call identification" feature 




Ongoing call (external or internal) 




CC-INFO 



« CALLING PARTY NUIVIBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type/subtype = 'Call identifier', 

value = 'waiting call id' > 
» 

CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type/subtype = 'Call identifier', 

value = 'waiting call id' > 



Figure 6: Call waiting indication 

NOTE 3: The line identifier indicates to the PP on which line the waiting call occurred (if external). It is however 
ignored on PP side if the PP does not implement the "Line identification" feature. 

NOTE 4: Unlike the call identifier which is a kind a session-id for the waiting call and is always present, the line 
identifier is only repeated here as a result of the "CALL-INFORMATION completeness principle" (see 
clause 3.1). It is however ignored if the PP does not implement the "Line identification" feature. 

To accept the waiting call, the "Call waiting acceptation" procedure shall be used (see clause 7.4.3.5.6). 

To reject the waiting call, the "Call waiting rejection" procedure shall be used (see clause 7.4.3.5.7). 

If the remote party hangs up before the waiting call has been accepted or rejected, the FP shall send a call release to the 
PP, using "Call release and call release rejection" of clause 7.4.3.5.4, if the PP implements the "Call identification" 
feature, or using "On-hold call release" otherwise. 



7.4.3.5.3 



Call toggle (external or internal) 



This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 
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In case two parallel calls are established, in order to toggle between the calls, the PP shall send the control code ICH as 
keypad information in a {CC-INFO} message, followed by 31H. Furthermore: 

• If the PP implements the "Call identification" feature, it shall send the identifier of the call targeted by the 
togggle in a «CALL-INFORMATION» information element included in the same {CC-INFO} message. 

NOTE 2: A PP implementing the "Call identification" feature sends the call identifier of the targeted call, even if it 
toggles between two calls only. 

• If the PP implements the "Line identification" feature, and the targeted call is external, it shall send the line 
identifier of the targeted call in a «CALL-INFORMATION» information element (the same one if the call 
identifier is also sent), even if it is attached to a single line. 

NOTE 3: If the call identifier is absent, the line identifier may help determine the targeted call; if the call identifier 
is present, the line identifier is only added as a result of the «CALL INFORMATION» completeness 
principle (see clause 3.1). 

The FP may change the codec using the service change procedure (see clause 7.4.3.3, "Codec change for parallel 
calls"). 

The FP may indicate the connected party by sending the «CALLING PARTY NUMBER» information element or by 
sending an appropriate «"DISPLAY"» information element in a {CC-INFO} message to the PP. 



PP FP 




<^ Ongoing calls (external or internal) J^ 






CC-INFO 






« MULTI-KEYPAD, info = '1C 31'H » 
« CALL-INFORMATION, 




Line of the targeted call < id type = 'Line identifier', subtype = 'external call', 
if external (see note 3) ^ value = 'targeted call line id' = 'u' > 


If the PP implements < id type/subtype = 'Call identifier', 
the "Call identification" feature value = 'targeted call id' > 






» 





7.4.3.5.4 



Figure 7: Call toggle request 



Call release and call release rejection 



This procedure applies to the FP and a PP already involved in at least two calls on a DECT system implementing the 
feature entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

A "Call release" message may be sent either by the PP, or by the FP. 

In case at least two parallel calls are established with one PP, and in order to release one of these calls, the releasing 
party (either the PP or the FP) shall send the control code ICH as keypad information in a {CC-INFO} message, 
followed by 33H. Additionally: 

• If the PP implements the "Call identification" feature, the releasing party shall send the identifier of the call to 
be released in a «C ALL-INFORM ATION> information element included in the same {CC-INFO} message. 
Furthermore, if the releasing party also implements the "Line identification" feature (i.e. always if the 
releasing party is the FP), and the call to be released is external, it shall send the line identifier of the call to be 
released in the same «CALL-INFORMATION» information element. 

NOTE 2: As the call identifier is unique within the DECT system, both parties already know in the above case 

which line is used for the call to be released. The line identifier is therefore present here as a result of the 
«CALL INFORMATION» completeness principle (see clause 3.1). 
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NOTE 3: If the PP implements the "Call identification" feature, a call release can be sent in any direction as soon as 
a call identifier has been sent by the FP to the PP (e.g. even before a waiting call has been answered). See 
also clause C.4.1.5. 

• if the PP does not implement the "Call identification" feature, the call release request shall be interpreted by 
both parties as a request for releasing the active call. If the PP is the releasing party and implements the "Line 
identification" feature, it shall still send the line identifier of the call to be released in a 

«CALL-INFORMATION» information element included in the same {CC-INFO} message. If the FP is the 
releasing party, it shall still send the line and call identifiers of the active call (to be released) in a 
«C ALL-INFORM ATION» information element included in the same {CC-INFO} message (and regardless 
of whether the PP implements the "Line identification" feature or not). 

If the released call is the active call, the speech path shall be then automatically switched to one of the remaining 
parties. 



PP 



FP 




Ongoing calls (external or internal) 




CC-INFO 



Line of tine call to be released 
if external (see note 2) 

if tfie PP implements 

the "Call identification" feature 



« MULTI-KEYPAD, info = '1C 33'H » 
« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'line id of call to be released' > 

< id type/subtype = 'Call identifier', 

value = 'id of call to be released' > 



If call cannot be released 



CC-INFO 



« SIGNAL value = 'negative ack tone' = 
« CALL-INFORMATION, 



'09'H » 



Line of tfie call to be released, 
if external (see note 4) 

Ignored if tfie PP does not implement 
the "Call identification" feature 



< id type = 'Line identifier', subtype = 'external call', 
value = 'waiting call line id' > 

< id type/subtype = 'Call identifier', 
value = 'waiting call id' > 



Figure 8: Call release request from the PP 

NOTE 4: Unlike the call identifier which is a kind a session-id for a call and is always present, the line identifier is 
only repeated here as a result of the "CALL-INFORMATION completeness principle" (see clause 3.1). It 
is however ignored on PP side if the PP does not implement the "Line identification" feature. 

In some cases, when the request is sent by the PP, the FP might not be able to fulfil it, for instance when the call to be 
released is external. In that case, the FP shall warn the user by sending the « SIGNAL » information element with 
the value 09H indicating negative acknowledgement tone. 

The FP may change the codec using the service change procedure (see clause 7.4.3.3, "Codec change for parallel 
calls"). 

The release by the PP of a parallel call shall not be possible in a conference. However, the FP could send a call release 
according to procedure "Call release and call release rejection" of clause 7.4.3.5.4 (or clause 7.4.3.5.5 if the PP does not 
implement the "Call identification" feature) if one of the remote parties hangs up. 

To release the last parallel call, the PP shall not use this procedure, but use a {CC-RELEASE} message instead. A 
{CC-RELEASE} message shall not convey any call identifier, even if the PP implements the "Call identification" 
feature. 

NOTE 5: To release all parallel calls, the PP may also send a single {CC-RELEASE} to the FP. 
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7.4.3.5.5 On-hold call release 



This procedure applies to the FP and a PP already involved in at least two calls on a DECT system implementing the 
feature entitled "Common parallel call procedures (external or internal)". 

This procedure is provided as an addition to the "Call release" procedure, for the case the PP does not implement the 
"Call identification" feature. In that case, it shall be used by both parties. 

A "On-hold call release" request may be sent either by the PP, or by the FP. 

In case at least two parallel calls are established with a PP not implementing the "Call identification" feature, and in 
order to release the on-hold call, the releasing party (either the PP, or the FP) shall send the control code ICH as keypad 
information in a {CC-INFO} message, followed by 37H. Additionally: 

• If the releasing party implements the "Line identification" feature, and the call to be released is external, it 
shall send the line identifier of the call to be released in a «CALL-INFORMATION» information element, 
even if the PP is attached to a single line. 

NOTE 1 : As no call identifier is send for this procedure, the line identifier may help the other party determine 
which call is to be released. 

In some cases, when the request is sent by the PP, the FP might not be able to fulfil it, for instance when the call to be 
released is external. In that case, the FP shall warn the user by sending the information element «SIGNAL» with the 
value 09H indicating negative acknowledgement tone. 

The FP may change the codec using the service change procedure (see clause 7.4.3.3, "Codec change for parallel 
calls"). 

The release by the PP of a parallel call shall not be possible in a conference. However, the FP shall send a call release 
according to present procedure to the PP if it initiated a 3-party conference call, and if the remote party that was on-hold 
when the conference call was initiated hangs up. 

NOTE 2: In order to release all parallel calls, the PP sends a {CC-RELEASE} to the FP. 

7.4.3.5.6 Call waiting acceptation (from PP to FP) 

This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a line, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In case the PP is already involved in a call (active call) and after a call waiting has been indicated, the acceptation of the 
waiting call shall be done by sending the control code ICH as keypad information in a {CC-INFO} message, followed 
by 35H. Furthermore, 

• If the PP implements the "Call identification" feature, it shall send the call identifier of the accepted waiting 
call in a «CALL-INFORMATION» information element included in the same {CC-INFO} message. 

NOTE 2: A PP implementing the "Call identification" feature sends the call identifier of the waiting call, even if 
there is a single call waiting. 

• If the PP implements the "Line identification" feature, and the waiting call is external, it shall send the line 
identifier of the waiting call in the same «CALL-INFORMATION» information element, even if it is 
attached to a single line. 

NOTE 3: If the call identifier is absent, the line identifier may help determine the targeted call; if the call identifier 
is present, the line identifier is only added as a result of the «CALL INFORMATION» completeness 
principle (see clause 3.1). 

The active call shall be automatically put on hold and the waiting call shall become active. 
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In "multiple call" mode, when the PP accepts the waiting call, ongoing procedures for handling the call on other PPs 
(using the present clause, or EN 300 444 (GAP) [12] clause 8.12, "Incoming call request", if it is a first call for the 
concerned PP) shall be terminated. In particular, idle PPs shall stop ringing. If several handsets either pick-up or accept 
the waiting call, only the first action shall be taken into account. The other actions shall be ignored. 

The FP may change the audio codec for the accepted call by use of the service change procedure. 

PP FP 



CW tone 
heared by user 




Ongoing call (external or internal) 




CC-INFO 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« SIGNAL value = 'call waiting tone' = '07'H » 
« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 
value = 'waiting call line id' > 



Line on which waiting call 
occurred if external (see note 4) 

Ignored if the PP does not implement < id type = 'Call identifier', 
the "Call identification" feature value = 'waiting call id' > 

» 



CC-INFO 




Internal or external 
waiting call waiting 
fom calling number' 



« MULTI-KEYPAD, info = '1C 35'H » 
« CALL-INFORMATION, 



In multiple call mode, 
other handsets stop 
ringing or receiving the 
CW indication 



Line on which waiting call 
occurred if external (see note 3) 

If the PP implements 

the "Call identification" feature 



< id type = 'Line identifier', subtype = 'external call', 
value = 'waiting call line id' > 

< id type = 'Call identifier', 
value = 'waiting call id' > 



Figure 9: Call waiting acceptation 

NOTE 4: The line identifier indicates to the PP on which line the waiting call occurred (if external). It is however 
ignored on PP side if the PP does not implement the "Line identification" feature. 

If the remote party hangs up before the waiting call has been accepted or rejected, the FP shall send a call release to the 
PP, using "Call release and call release rejection" of clause 7.4.3.5.4, if the PP implements the "Call identification" 
feature, or using "On-hold call release" otherwise. 



7.4.3.5.7 



Call waiting rejection (from PP to FP) 



This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a line, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

NOTE 1 : Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In case the PP is already involved in a call (active call) and after a call waiting has been indicated, the rejection of the 
waiting call shall be done by sending the control code ICH as keypad information in a {CC-INFO} message, followed 
by 36H. Furthermore, 

• If the PP implements the "Call identification" feature, it shall send the call identifier of the rejected waiting call 
in a «CALL-INFORMATION» information element included in the same {CC-INFO} message. 

NOTE 2: A PP implementing the "Call identification" feature sends the call identifier of the waiting call, even if 
there is a single call waiting. 

• If the PP implements the "Line identification" feature, and the waiting call is external, it shall send the line 
identifier of waiting call in the same «CALL-INFORMATION» information element, even if it is attached 
to a single line. 
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NOTE 3: If the call identifier is absent, the line identifier may help determine the targeted call; if the call identifier 
is present, the line identifier is only added as a result of the «CALL INFORMATION» completeness 
principle (see clause 3.1). 



PP 



FP 



CW tone 
heard by user 



Line on which waiting cail 
occurred if external (see note 4) 

Ignored if the PP does not implement 
the "Call identification" feature 




Ongoing call (external or internal) 




CC-INFO 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« SIGNAL value = 'call waiting tone' = '07'H » 
« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Call identifier', 

value = 'waiting call id' > 
» 

CC-INFO 




Internal or external 
waiting call waiting 
from 'calling number 



Line on which waiting call 
occurred if external (see note 3) 

if the PP implements 

the "Call identification" feature 



« MULTI-KEYPAD, info = '1C 36'H » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'selected line id' > 

< id type = 'Call identifier', 

value = 'waiting call id' > 



In multiple call mode, 
other handsets continue 
rinqinq or receiving the 
CW indication 



for this PP only: 



CC-INFO 



Line on which waiting call 
occurred if external (see note 3) 

Ignored if the PP does not implement 
the "Call identification" feature 



« SIGNAL, value = 'Tones off = '3F'H » 
« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type = 'Call identifier', 

value = 'waiting call id' > 



Figure 10: Call waiting rejection 



NOTE 4: The line identifier indicates to the PP on which line the waiting call occurred (if external). It is however 
ignored on PP side if the PP does not implement the "Line identification" feature. 



NOTE 5: On a multiple call line configured in "multiple call" mode, 
imply that the call is rejected by the DECT system. 



'call waiting rejection" does not necessarily 



In "multiple call" mode, when the PP rejects the waiting call, the "Call waiting indication procedure" shall be 
terminated for this PP, but this shall not affect the handling of this call on other handsets: ongoing procedures for 
handling the call on other PPs (using the present clause or EN 300 444 [12] (GAP), clause 8.12, "Incoming call request" 
if it is a first call for the concerned PP) shall not stop. In particular, idle PPs shall not stop ringing. 

NOTE 6: To reject the call for the whole DECT system, a call release may be used instead of the present procedure, 
using the "Call release and call release rejection" of clause 7.4.3.5.4 for the waiting call if the PP 
implements the "Call identification" feature, or using "On-hold call release" of clause 7.4.3.5.5 otherwise. 
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If the remote party hangs up before the waiting call has been accepted or rejected, the FP shall send a call release to the 
PP, using "Call release and call release rejection" of clause 7.4.3.5.4, if the PP implements the "Call identification" 
feature, or using "On-hold call release" of clause 7.4.3.5.5 otherwise. 



7.4.3.5.8 



Putting a call on-hold 



This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In order to put a call on-hold, the PP shall send the control code ICH as keypad information in a {CC-INFO} message, 
followed by 41H. Furthermore: 

• If the PP implements the "Call identification" feature, it shall send the identifier of the call to be put on-hold in 
a «CALL-INFORMATION» information element included in the same {CC-INFO} message. 

NOTE 2: A PP implementing the "Call identification" feature sends the call identifier of the call to be put on hold, 
although it is always the active call. 

• If the PP implements the "Line identification" feature, and the call to be put on hold is external, it shall send 
the line identifier of the call to be put on hold, in the same «CALL-INFORMATION» information element, 
even if it is attached to a single line. 

NOTE 3: If the call identifier is absent, the line identifier may help determine the targeted call; if the call identifier 
is present, the line identifier is only added a result of the «CALL INFORMATION» completeness 
principle (see clause 3.1). 

The FP may indicate the result of the present procedure by sending an appropriate «"DISPLAY"» information 
element in a {CC-INFO} message to the PP. 



PP 



FP 





^^^ Ongoing calls (external or internal) ^^> 






CC-INFO 




« MULTI-KEYPAD, info = '10 41'H » 
« CALL-INFORMATION, 


^ 


Line of the call to be put on hold 
if external (see note 3) 


< id type = 'Line identifier', subtype = 'external call', 
value = 'targeted call line id' = 'u' > 


If the PP implements 

the "Call identification" feature 


< id type = 'Call identifier', 
value = 'targeted call id' > 




» 



Figure 1 1 : Putting a call on hold 



7.4.3.5.9 



Resuming a call put on-hold 



This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". 

NOTE 1: Implementation of the "Multiple call" feature or of the "Multiple line" feature implies implementation of 
the "Common parallel call procedures (external or internal)" feature. 

In order to resume a call that was put on-hold, the PP shall send the control code ICH as keypad information in a 
{CC-INFO} message, followed by 42H. Furthermore, 

• If the PP implements the "Call identification" feature, it shall send the identifier of the call to be resumed in a 
«CALL-INFORMATION» information element included in the same {CC-INFO} message. 
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NOTE 2: A PP implementing the "Call identification" feature sends the call identifier of the call to be resumed, 
even if there is only one call on-hold. 

• If the PP implements the "Line identification" feature, and the call to be resumed is external, it shall send the 
line identifier of the call to be resumed, in the same «CALL-INFORMATION» information element, even 
if it is attached to a single line. 

NOTE 3: If the call identifier is absent, the line identifier may help determine the targeted call; if the call identifier 
is present, the line identifier is only added as a result of the «CALL INFORMATION» completeness 
principle (see clause 3.1). 

The FP may indicate the result of the present procedure by sending an appropriate «"DISPLAY"» information 
element in a {CC-INFO} message to the PP. 



PP 



FP 





<:;;^ Ongoing calls (external or internal) J^ 






CC-INFO 




« MULTI-KEYPAD, info = '1C 42'H » 
« CALL- INFORMATION, 




Line of the call to be resumed 
if external (see note 3) 


< id type = 'Line identifier', subtype = 'external call', 
value = 'targeted call line id' = 'u' > 


If the PP implements 

the "Call identification" feature 


< id type = 'Call identifier', 
value = 'targeted call id' > 




» 



Figure 12: Resuming a call put on hold 



7.4.3.5.10 



CLIP on call waiting 



This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a line, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

CLIP on call waiting shall be indicated by the FP to the PP. 

This indication shall be done by sending in a {CC-INFO} message the information element «Calling Party Numbei». 

If the waiting call is an internal call, the information element «Calling Party Number» shall indicate a private 
numbering plan. 



PP 



FP 




Call established 




CC-INFO 



« SIGNAL, value = '07H' » 



CC-INFO 



: CALLING PARTY NUMBER : 



Figure 13: CLIP on call waiting 
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7.4.3.5.11 



CNIP on call waiting indication 



This procedure applies to the FP and a PP already involved in a call on a DECT system implementing the feature 
entitled "Common parallel call procedures (external or internal)". If the "Multiple call" feature is implemented on a line, 
the line may be configured in "single call" mode, or in "multiple call" mode. 

CNIP on call waiting shall be indicated by the FP to the PP. 

This indication shall be done by sending in a {CC-INFO} message the information element «Calling Party Name». 



PP 




FP 



Call established 




CC-INFO 



: SIGNAL, value ='07H' 



CC-INFO 



: CALLING PARTY NAME : 



Figure 14: CNIP on call waiting 

NOTE: In case both CLIP and CNIP are sent to the PP, it is sufficient to display one of them. It is optional to 
display both. 



7.4.3.6 



Call transfer 



Call transfer is used by the user of a PP involved in two parallel calls to connect the remote parties together before 
ending the existing calls. If one of the remote parties is a handset registered to the same FP, the transfer can be handled 
at FP level; otherwise, the success of the transfer is network-dependent. 

Implementation of the "Common parallel calls procedures" feature is a pre-requisite on PP and FP sides for 
implementation of the "Call transfer" feature. 

The call transfer may be announced or unannounced, depending on when the call transfer control message is sent by the 
PP. 

In order to transfer a call, the PP shall first establish a parallel call with the call transfer target, and then send the control 
code ICH as keypad information in a {CC-INFO} message, followed by 34H. Furthermore, 

• If the PP implements the "Call identification" feature, it shall send the identifier of the call to be transferred in 
a «CALL-INFORMATION» information element included in the same {CC-INFO} message. 

• If the PP implements the "Line identification" feature, and the call to be transferred is external, it shall send the 
line identifier of the targeted call in a «CALL-INFORMATION» information element (the same one if the 
call identifier is also sent), even if it is attached to a single line. 

The FP shall understand a call tranfer request as a request for transferring the previously active call to the currently 
active call. It shall issue a call identifier update for the PP target of the call transfer, as shown in figures 13 and 14, 
indicating the call identifier of the transferred call as updated call identifier. 

If the previously active call has been released in the mean time, the call transfer shall fail but the currently active call 
shall still be released. 

When implementing the "Call transfer" feature, the FP shall set bit a3Q of the "Extended higher layer capabilities 
(part 2)" (see EN 300 175-5 [5], clause F.3). Consistently with the above description, bit a3]^ must also be set. 
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7.4.3.6.1 



Announced call transfer procedure 



For the "Announced call transfer" procedure, all requirements of clause 7.4.3.6 apply. Additionally, if the control code 
is sent after the {CC-CONNECT}, allowing for a transient call with the targeted PP, the transfer is defined as 
announced. 



PP1 



FP 



PP2 




call 1 established 
(external or internal) 



Try to establish parallel internal call 2 
CO-INFO 




« MULTI-KEYPAD, 1 7H + terminal id number » 



00-INFO 



Ignored if the PP does 

not implement 

the "Call identification" 

feature 



« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' ; 

< Identifier value = 'id for call 2'H > 



ring-back tone 
CC-INFO 



Ignored if the PP does 

not implement 

the "Call identification" 

feature 



« SIGNAL value = '01 'H» 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' : 

< Identifier value = 'id for call 2'H > 



Call transfer request 

CC-INFO 



Line of the transferred call 
if external 



I 



if the PP implements 
the "Call identification" 
feature 



« MULTI-KEYPAD, info = '1C 34'H » 
« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'external call' >, 

< Identifier value = 'transferred call line id' 

< Identifier type = 'Call identifier' > 

< identifier subtype = 'Call identifier' > 

< identifier value = 'id for call 1'H > 

CC-RELEASE 



CC-RELEASE-COM 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' 

< Identifier value = 'id for call 2'H > 



CC-SETUP-ACK 



CC-CONNECT 



Call 
pick-up 



CC-INFO 



« CALL-INFORMATION, 

< identifier type = 'Line identifier' > 

< Identifier subtype = 'external call' >, 

< Identifier value = 'transferred call line id' 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' 

< identifier value = 'id for call 2'H > 

< identifier type = 'Call identifier' > 

< identifier subtype = 'Updated caii id' > 

< Identifier value = 'id for call 1'H > 



Figure 15: Announced call transfer (example with internal target PP2): 
"call transfer request" after {CC-CONNECT} 

NOTE 1: The Call Control message sequence in figure 15 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 2: On a "single call" mode line, PP2 is always idle. On a "multiple call" mode line, PP2 may be idle or busy. 
If busy, PP2 would receive a call waiting indication instead of a CC-SETUP, and would send a 'Call 
waiting acceptation" instead of a CC-CONNECT. 

NOTE 3: A multiple call line may not support the additional internal call. In that case, PPl will receive back a busy 
tone signal, which will terminate the procedure. 

NOTE 4: In figure 15, the second call is established using the "Outgoing parallel call initiation" procedure of 
clause 7.4.3.5.1; however, any procedure leading to two parallel calls may precede the call transfer 
procedure. 
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7.4.3.6.2 



Unannounced call transfer procedure 



For the "Unannounced call transfer" procedure, all requirements of clause 7.4.3.6 apply. Additionally, if the control 
code is sent after reception of the ring back tone but before the {CC-CONNECT} (pick up time), the transfer is defined 
as unannounced. 



PP1 



FP 



PP2 




call 1 established 
(external or internal) 



Try to establish parallel internal call 2 

CC-INFO 




« MULTI-KEYPAD, 17H + terminal id number » 



CC-INFO 



Ignored if the PP does 

not implement 

the "Gall identification" 

feature 



« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' 

< Identifier value = 'id for call 2'H > 



Ring-back tone 

CC-INFO 



« SIGNAL value = '01 'H» 
Ignored if the PP does « CALL-INFORMATION, 

not implement < Identifier type = 'Call identifier' > 

the "Call identification" < Identifier subtype = 'Call identifier' : 

feature < Identifier value = 'id for call 2'H > 



Call transfer request 

CC-INFO 



Line of the transferred call 
if external 

If the PP implements 
the "Call identification" 
feature 



« MULTI-KEYPAD, info = '1C 34'H » 
« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'external call' >, 

< Identifier value = 'transferred call line id' 

< Identifier type = 'Call identifier'> 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'id for call 1'H > 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' 

< Identifier value = 'id for call 2'H > 



CC-SETUP-ACK 



Examplel of CC-CONNECT position 
in unannounced cail transfer 

CC-CONNECT 



Call 
pick-up 



CC-INFO 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'external call' >, 

'u' > < Identifier value = 'transferred call line id' = 'u' > 

< Identifier type = 'Call identifier'> 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'id for call 2'H > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Updated call id' > 

< Identifier value = 'id for call 1'H > 



CC-RELEASE 



CC-RELEASE-COM 



Example 2 of CC-CONNECT position 
in unannounced cali transfer 

CC-CONNECT 



Call 
pick-up 



Example 3 of CC-CONNECT position 

in unannounced call transfer Call 

CC-CONNECT pick-up 



Figure 16: Unannounced call transfer (example with internal target PP2): 
"call transfer request" before {CC-CONNECT} 

NOTE 1: The Call Control message sequence in figure 16 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 2: On a "single call" mode line, PP2 is always idle. On a "multiple call" mode line, PP2 may be idle or busy. 
If busy, PP2 would receive a call waiting indication instead of a CC-SETUP, and would send a "Call 
waiting acceptation" instead of a CC-CONNECT. 
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NOTE 3: A multiple call line may not support the additional internal call. In that case, PPl will receive back a busy 
tone signal, which will terminate the procedure. 

NOTE 4: In figure 16, the second call is being established using the "Outgoing parallel call initiation" procedure of 
clause 7.4.3.5.1; however, any procedure leading to two parallel calls may precede the call transfer 
procedure. For example, unannounced call transfer could also be used instead of call waiting acceptation 
after the "Call waiting indication" procedure. 



7.4.3.6.3 



Call re-injection to the line (external or internal) 



The purpose of the "Call re-injection to the line (external or internal)" procedure is to transfer a call (external or 
internal) unannounced to all PPs attached to the line. 



PP1 



FP 





Call 1 established 
(external or internal) 



Initiate setup of parallel internal general call 

CC-INFO 



« MULTI-KEYPAD, 17H + '*' » 

Call transfer request 

CC-INFO 



« MULTI-KEYPAD, '1C 34'H » 
CC-RELEASE 



CC-RELEASE-COM 



r 



For each idle PP < 



r 



For each PP already in use j 
(if the line implements the "Multiple calls" A 
feature and is in "multiple call" mode) 



V 



Any PP 

attached to the 
same line 



Paging of the idle PP 




CC-SETUP 



CC-SETUP-ACK 



If this PP picks up: 

CC-CONNECT 



unannounced call transfer complete 



CW indication to the PP in use 
CC-INFO 



« CALLING PARTY NUMBER » 
« SIGNAL value = 'CW = '07'H » 

If this PP accepts the waiting call 

CC-INFO 



« "KEYPAD", info = '1C 35'H » 
unannounced call transfer complete 



Figure 17: Use of 'unannounced call transfer' as a way to re-inject a call into the line 

NOTE: The Call Control message sequence in figure 17 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 
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7.4.3.6.4 Remote party CLIP on call transfer 

"Remote party CLIP on call transfer" shall be used when a call transfer occurs between the remote parties of a double 
call. It is defined as follows: 

• A first call between a first party (A, transferring party) and a second party (B, "remote" party) is supposed to 
have been completely established. This first call may be external or internal. 

• A second internal call between A and a third party (C, the PP target of the call transfer) is either already 
established (announced call transfer) or being established (unannounced call transfer). "Remote party CLIP on 
call transfer" shall be used on announced or unannounced call transfer. 

"Remote party CLIP on call transfer" occurs in the FP after reception of the "call transfer request" from the transferring 
party. The remote party CLIP (of B) shall be indicated by sending the «Calling Party Number» information element 
in a {CC-INFO} message. 

NOTE 1 : "Remote party CLIP on call transfer" is applicable when the third party C is internal (that is, registered to 
the same PP as the transferring party A). 

NOTE 2: C successively receives the usual CLIP (of A) and the "Remote party CLIP on call transfer" (of B). 

7.4.3.6.5 Remote party CNIP on call transfer 

The "Remote party CLIP on call transfer" procedure applies unchanged, except that CLIP is replaced everywhere with 
"CNIP". 

NOTE 1 : In case both CLIP and CNIP are sent to the PP, it is sufficient to display one of them. It is optional to 
display both. 
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FP 




B 
(internal or external) 



C 

(internal) 



call 1 established 



establish parallel internal call 2 
CC-INFO 



« MULTI-KEYPAD, info = '17'H + number » 



ring-bacl< tone 
CC-INFO 



« SIGNAL value = '01 'H» 
call transfer request 

CC-INFO 



« MULTI-KEYPAD, info = '1C 34'H » 




CC-SETUP (see note 4) 



« CALLING PARTY NUMBER » of A 
« CALLING PARTY NAME » of A 

CC-SETUP-ACK 



if announced call transfer 
CC-CONNECT 



if unannounced call transfer 
CC-CONNECT 



Remote party CLIP on call transfer 

CC-INFO (see note 4) 



« CALLING PARTY NUMBER » of B 
«CALLING PARTY NAME » of B 

if unannounced call transfer 
CC-CONNECT 



Call 
pick-up 



Call 
picl<-up 



Call 
pick-up 



Figure 18: Remote party CLIP and CNIP on call transfer 

NOTE 2: The Call Control message sequence in figure 18 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 3: On figure 18, three possible positions for the CC-CONNECT message are shown. 

NOTE 4: CNIP for internal handsets is handled according to the provisions of GAP "Internal Call CNIP" procedure 
(GAP clause 8.44). 

NOTE 5: CNIP and CLIP might not fit in a single message; in that case one or more additional {CC-INFO} 
message(s) are used. 



7.4.3.7 



3-party conference with established external and/or internal calls 



The 3-party conference takes place either between 3 PPs on the same FP (based on 2 internal calls), or between 2 PPs 
and one remote party (based on one internal + one external calls), or between 1 PP and 2 remote parties (based on 
2 external calls). 

If the "Multiple lines" feature is implemented, the calls may be on two different lines. 

In case two parallel calls are established or a waiting call was indicated, in order to establish a conference, the PP shall 
send the control code ICH as keypad information in a {CC-INFO} message, followed by 32H. Furthermore, 

• If the PP implements the "Call identification" feature, it shall send the call identifier of the current active call 
in a «CALL-INFORMATION» information element included in the same {CC-INFO} message. 
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• The FP shall use this active call id (even if the PP did not send it) as the call id for the conference call. If 

additional non-initiating PPs are involved in the conference call, the FP shall issue a call identifier update for 
each of them, as shown in figure 19. 

NOTE 1: In a 3-party conference call, all PPs involved in the conference share the same call identifier for the 
3-party call. 

The FP may change the codec using the service change procedure (see clause 7.4.3.3, "Codec change for parallel 
calls"). 

When implementing the "Call transfer" feature, the FP shall set bit agg of the "Extended higher layer capabilities 
(part 2)" (see EN 300 175-5 [5], clause F.3). Consistently with the above description, bit a3]^ must also be set. 



PP 




Calls established 



CC-INFO 



FP 




«MULTI-KEYPAD, 1CH 32H » 

Only if the PP « CALL-INFORMATION, 
implements ^ Identifier type = 'Call identifier' > 
the "Call identification" < Identifier subtype = 'Call identifier' > 

feature "^ identifier value = 'active call id' = '3-party call id'H > 



Figure 19: 3-party conference call establishment request 

If the PP is involved in more than 2 calls, the FP shall warn the user by sending the « SIGNAL » information 
element with the value 09H indicating negative acknowledgement tone. 

The release by the PP of one of the parallel calls shall not be possible in a conference. However, the FP could send a 
call release according to procedure "Call release and call release rejection" of clause 7.4.3.5.4 (or clause 7.4.3.5.5 if the 
PP does not implement the "Call identification" feature) if one of the remote parties hangs up. 



PP 




3-party conference established 



{CC-RELEASE} 



{CC-RELEASE-COIVI} 



FP 




Figure 20: 3-party conference release 

NOTE 2: For the initiating PP, sending a {CC-RELEASE} message releases the conference. For a non-initiating 
PP, sending a {CC-RELEASE} message withdraws that non-initiating PP from the conference. 
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PP1 



FP 



PP2 




Only if the PP 

implements 

the "Call identification" 

feature 



internal call established, (external or internal), 
with call-id 1 



other call established 
(external or internal) 



3-party conference call request 
CC-INFO 




« MULTI-KEYPAD, info = '1C 32'H » 
« CALL-INFORIVIATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = '3-party call id'H > 




CC-INFO 



« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' 

< Identifier value = 'call-id 1 'H > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Updated call id' > 

< Identifier value = '3-party call id'H > 



7.4.3.8 



Figure 21 : Call id update for the non-initiating PP 



Call intrusion (from PP to FP) 



Call intrusion is a simple way to set up a 3-party conference call, with an existing external active call on another PP. 
This service mimics the usual behavior of two PSTN wired phones connected to the same physical analogue line. 

NOTE: Call intrusion is also known as "barging-in". 

This feature makes optional use of the "Line identification" feature on PP side. 



7.4.3.8.1 



Implicit call intrusion into a line in "single call" mode 



This procedure applies to the FP and an idle PP on a line either not implementing the "Multiple calls" feature, or 
implementing this feature but configured in "single call" mode. 

NOTE 0: "Implicit call intrusion" if implemented should be a configurable feature of the single call mode line. 

If PPl is involved in an active external call and PP2 wishes to participate in a 3-party conference with PPl and the 
remote party: 

• PP2 shall attempt to get the external line with a {CC-SETUP}. The call identifier assigned by the FP for this 
call shall be the call identifier for the intruded call. This message shall then be directly acknowledged by the 
FP with a {CC-CONNECT} message. 

• The FP shall notify PPl with a {CC-INFO} message containing the information element «SIGNAL» with 
the value 02H indicating 'Intercept tone on'. 

The FP shall generate automatically a conference call audio stream between the three parties. 
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PP2 

attached to line u 



PP1 

attached to line u 



FP 



Network 



The PP sets up the call and 
selects the line to be used; 



External Call established with call id 1 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 



CC-INFO 



^ \ 

« CALL-INFORIVIATION, 

< Id type = 'Line identifier', subtype = 'external', value = 

< Id type/subtype = 'Call identifier', value = 'call id 1' > 
» 

CC-CONNECT 



u > 



CC-INFO 



« SIGNAL, value = '02'H » 
PP2 «CALLING-PARTY-NUMBER» 
« CALL-INFORMATION, 



Ignored if the PP does not implement 
the "Call identification" feature 



< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 



tier type = 'Line identifier' 

tier subtype = 'Line identifiler for external calls' > 

tier value = 'u' > 

tier type = 'Call identifier' > 

tier subtype = 'Call identifier' > 

tier value = 'call id 1' > 



3-party call establishment 



Figure 22: Implicit call intrusion 

NOTE 1 : The Call Control message sequence in figure 22 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 

NOTE 2: In addition to the "Intercept tone on" signal, Call waiting with the same call id warns PPl of a call 
intrusion attempt. 

NOTE 3: If the selected line is not a "single-call" mode line, the DECT system will try to make an outgoing call. 



7.4.3.8.2 



Explicit call intrusion 



This procedure applies to the FP and an idle PP on a line implementing the "Multiple calls" feature and configured in 
"multiple call" mode or in "single call" mode. In this case, the PP intrudes a call by using a specific control code for 
"call intrusion" while initiating the setup of an external call. 
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PP2 

intruding PP, 
attached to line u 



Tine PP sets up tine call 
and selects the line to be 
used (line of the call to 
be intruded): 



Targeted handset (optional) 



PP1 in a call 

intruded PP, 
attached to line u 



CC-SETUP 



FP 



Network 



Ongoing external call with call id 1 



« CALL-INFORIVIATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = 'u' > 



---r— 

CC-INFO 



< \ 

« CALL-INFORMATION, 

< Id type = 'Line identifier', subtype = 'external', value = 'u' > 

< Id type/subtype = 'Call identifier', value = 'call id 2' > 



CC-INFO 



« IVIULTI-KEYPAD. 



Keypad info = '1C40'H 



CC-INFO' 



« MULTI-KEYPAD, 

< Keypad info = 'targeted terninal id number' > » 



T" 



CC-INFO 



-I- 
« CALL-INFORMATION, 

< Id type = 'Line identifier', subtype = 'external', value = 'u' > 

< Id type/subtype = 'Call identifier', value = 'call id 2' > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Updated call id' > 

< Identifier value = 'call id 1 ' > 



» 

H — 



CC-CONNECT 



CC-INFO 



Ignored if the PP does not implement 
the "Call identification" feature. 
See also note 2. 



« SIGNAL, value = '02'H » 
PP2 «CALLING-PARTY-NUMBER» 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier 

< Identifier subtype = 'Line ident tier for external calls' > 

< Identifier value = 'u' > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call id 1' > 



3-party call establishment 



Figure 23: Successful explicit call intrusion 

NOTE 1 : The Call Control message sequence in figure 23 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 
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If PPl is involved in an active external call and PP2 wishes to participate in a 3-party conference with PPl and the 
remote party: 

• PP2 shall attempt to get the external line with a {CC-SETUP}. The FP assigns a call identifier for this new 
setup call. 

NOTE 2: At this stage, the FP does not know that there will be a call intrusion attempt and assigns a call identifier 
to this new call independently of the intruded call. This is in contrast to the "Implicit call intrusion" 
procedure. 

• PP2 then sends a call intrusion request, consisting in the control code ICH as keypad information in a 
{CC-INFO} message, followed by 40H, and optionally followed by the terminal id number of the handset 
owning the targeted call. As a result of this request: 

If a terminal id number is specified, and there is a call active on this terminal, this call shall be intruded. 

If no terminal id number is specified, but there is only one active call on the line, this only call shall be 
intruded. 

In all other cases, a CC-INFO message shall be returned back to the requesting PP with a «SIGNAL» 
information element with <Signal value> field equal to 09H (for negative acknowledgement). 

• The FP shall notify PPl with a {CC-INFO} message containing the information element «SIGNAL» with 
the value 02H indicating 'Intercept tone on'. 

The FP shall generate automatically a conference call audio stream between the three parties. 

NOTE 3: In addition to the "Intercept tone on". Call waiting with the same call id warns PPl of a call intrusion 
attempt. 

NOTE 4: In "multiple call" mode, simply initiating a call setup would lead to the setup of an additional call if the 
line can accept an additional call, or to a failure (busy tone signal received back). 

7.4.3.9 Internal call codec priority 

7.4.3.9.1 Description 

When performing an internal call between two wideband enabled PPs, the FP shall arrange that the call is finally 
established in a wideband codec rather than in a narrow band codec. Respectively in a super wideband codec rather than 
in a wideband or narrowband codec. 

As a consequence, in the particular case where both PPs present G.722 with highest priority, the internal call shall 
finally be established in ITU-T Recommendation G.722 [17]. 

Exception cases to this procedure are listed in clause 7.4.3.9.2. 

This procedure has been added to guarantee that the internal call will be established in the highest audio quality 
supported by both handsets involved in the internal call, at least when no other call is established at the same time in the 
DECT system. 

Two examples of support of this procedure are given hereafter: 

EXAMPLE 1 : When the «Codec List» information element is only specified at subscription registration and 
location registration phases. 

EXAMPLE 2: When the «Codec List» information element is specified at call setup phase. 

Figure 24 shows an example (example 1) with an internal call sequence where no codec list is specified at call setup and 
both PP-s support wideband (same codec list re-used as at location registration phase). 
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PP1 F 


P PF 




ACCESS RIGHTS-REQUEST 






« Codec List = G.722,...,G.726» 




ACCESS RIGHTS ACCEPT 






« Codec List G.722,...,G.726» 




LOCATE-REQUEST 






« Codec List = G.722,...,G.726» ^ 




LOCATE-ACCEPT 






« Codec List = G.722,...,G.726» 


Initiate an internal call 






CC-SETUP 


LCE REQUEST PAGE (long) 




«Basic Service=98» 




CC-CALL-PROC 








CC-SETUP 




«Basic Service=98» 




CC-CONNECT 


CC-CONNECT 




CC-CONNECT-ACK 




«Codec List = G.722» 


1 





Figure 24: Internal call with no codec list at call setup 

Figure 25 shows example 2 with an internal call sequence where the codec list is specified at call setup and both PPs 
support wideband. 



PP1 



FP 



PP2 



CC-SETUP 


LCE_REQUEST_PAGE (long) 


«Basic Service=98» "^ 
«Codec List = G.722, ...., G726» 

CC-CALL-PRQC 


CC-SETUP 


CC-CONNECT 


«Basic Service=98» 

«Codec List=G.722, ...., G726» 

CC-CONNECT 


«Codec List = G.722» 
CC-CONNECT-ACK 


«Codec List = G.722» 





Figure 25: Internal call with codec list at call setup 
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NOTE: The Call Control message sequences in figures 24 and 25 should be understood as examples. The real 

sequences may also contain different Call Control messages or Call Control messages in another order or 
Call Control messages with other contents. 

7.4.3.9.2 Exception cases 

Exception to the clause 7.4.3.9. No requirement applies in the following cases: 

1) Case of internal call transfer. In this case, the PP requesting the transfer may specify any order for the codecs 
in the «Codec List» information element. For example, the codec used in the initial ongoing external call to 
be transferred may be given the highest priority in the «Codec List» information element sent by the PP for 
the parallel call. This could avoid two codec switching: one for each PP involved in the transfer. 

2) Cases of multiple calls handled by the FP at the same time, if critical for FP hardware resources. 

3) Specific implementations of PPs that have to support narrow band headsets. 

4) Specific implementations of PPs where battery autonomy is very critical. 

7.4.4 Handling of single call services 
7.4.4.1 Control messages 

The following control codes shall be transmitted as keypad information in {CC-INFO} messages and shall trigger the 
corresponding actions in the FP. 

7.4.4.1 .1 Call deflection control messages 

Table 18: Control messages for control of single call services 



Procedure 


Control message 


Direction 


PP Status 


Call deflection (internal) 


1CH38H 17H + number 


PP to FP 


M 


Call deflection (external) 


1CH38H 15H + number 


PP to FP 


M 



Call deflection procedure for internal and external calls is detailed in clause 7.4.4.2. 

7.4.4.2 Call deflection 

The call deflection service enables the user to respond to an incoming call by requesting redirection of this call to 
another number specified in the response. The call deflection service can only be requested before the connection is 
established by the user, i.e. in response to the incoming call during the period that the user is being alerted of the call 
(see TS 122 072 [22]). 

In order to deflect a call in the "CALL RECEIVED" CC state, the PP shall send the control code ICH as keypad 
information in a {CC-INFO} message, followed by 38H and by the deflected-to telephone number. Deflected-to 
telephone number may be internal or external. 

NOTE 0: Deflection to an internal telephone number only makes sense if ringing groups have been defined and if 
the deflected-to terminal belongs to a different ringing group, for example in a multi-line context. 

It is recommended that the deflected-to telephone number is pre-configured (in the handset) before using this service. 
The PP related procedures to pre-program and display the deflected-to number is out of the scope of this procedure. 

If a user requests the call deflection service, and the deflected-to telephone number is external, the FP shall relay the 
service request to the network: 

• If the service can be provided, the FP shall notify the PP by releasing the incoming call. 

• If the service cannot be provided, the FP shall not release the incoming call and should proceed further with it. 

On the FP side, only the first call deflection request shall be taken into account. Possible further requests concerning 
this call and coming from the same or other PPs shall be ignored. 
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PP1 

CC-SETUP 


F 


P 


Netv 

1^ 


vork 




CC-SETUP-ACK 






call deflection request 
CC-INFO 








« "KEYPAD", '1C 38 15'H + number 


» 






<f CD activation ^ 






^ ^ 




if request accepted: ^^ ^^1 cacc 












CC-RELEASE-COM 












if request rejected (example): 








pici<-up 


CC-CONNECT 





Figure 26: Call deflection invocation when the deflected-to party is external 



PP1 



FP 



PP2 





CC-SETUP 




> 






CC-SETUP-ACK 






call deflection request 
CC-INFO 








;< "KEYPAD", '1C 38 17'H -i- number 


> 










CC-SETUP ^ 




if request accepted: 




CC-RELEASE 




« CALLING PARTY NUMBER» (see note) 






CC-SETUP-ACK 






CC-RELEASE-COM 












if reques 
pick-up 


t rejected (example): 

CC-CONNECT 


-► 









Figure 27: Call deflection invocation when the deflected-to party is internal 

NOTE 1: The Call Control message sequences in figures 26 and 27 should be understood as examples. The real 

sequences may also contain different Call Control messages or Call Control messages in another order or 
Call Control messages with other contents. 

NOTE 2: «CALLING PARTY NUMBER» is the deflected (remote) party calhng party number. It could also be 
sent in a CC-INFO message. 
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7.4.5 Line identification 

7.4.5.1 Line identification general requirements 

Line identifiers are used to identify the line on which an external call (incoming or outgoing) is made. 

When the "Multiple line" feature is also implemented, line identifiers allow to enhance the handling of parallel calls in 
the "Common parallel call procedures" feature. However, when the "Line identification" feature is implemented, line 
identifiers shall be sent even if there is only one line in the system. Furthermore, if there are several lines in the system 
(meaning that the "Multiple line" feature is also implemented), the line identifiers shall be used also for PPs attached to 
only one line. 

A party (PP or FP) shall send the line identifier in case it implements the "Line identification" feature, regardless of 
whether the other party implements the feature or not. If the other party does not implement the feature, it shall ignore 
the received line identifier. However, a PP implementing the feature may not send any line identifier if it uses the "FP 
managed line selection" procedure. 

Typically, a FP would use line identifiers in the 0..n interval, where 'n+l' represents the number of lines it handles. 

Several procedures outside of the "Line identification" feature itself also use line identifiers conditionally to the 
implementation of the "Line identification" feature. This includes procedures defined for the feature entitled "Common 
parallel calls procedures". 

A DECT system shall use the CALL-INFORMATION completeness principle (see clause 3.1). 

7.4.5.2 Line identification for external outgoing calls 

7.4.5.2.1 General line identification requirements for external outgoing calls 

For outgoing calls, the "Line identification" feature enables a PP to select the line on which the call has to be placed. If 
the PP does not send any line identifier, the "Line identification" feature enables the FP to notify back the PP of the line 
identifier for the selected line. 

This procedure applies to all external outgoing calls (first or parallel). In the case of a parallel call, it only applies if the 
feature entitled "Common multiple call procedures" is also implemented. In that case, relevant procedures are described 
there. 

The line identifier information shall be sent with one of the following methods: 

• Included in a « CALL INFORMATION » information element sent in the CC-SETUP message. 

• Included in a « MULTI-KEYPAD » information element sent either in the CC-SETUP message, or in a 
CC-INFO message. This method shall only be used if the line identifier is in the interval 0..9. If this method is 
used, the line identifier information shall consist in the pound key ("#") character ('23'H) followed by the line 
identifier digit, I A5 -coded on a single octet. 

7.4.5.2.2 Line identification for a //rsf external outgoing call using «CALL 
INFORMATION» 

This procedures applies to the FP and a PP effectively sending a line identifier for a first external outgoing call, using a 
«CALL-INFORMATION» information element. 

When using the present procedure, a « CALL INFORMATION » information element shall be used for conveying 
the line identifier information, this information element shall be included in the {CC-SETUP} message, as an addition 
to procedure "Outgoing call request" of GAP [12], clause 8.2. 
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Table 19: Values used within the {CC-SETUP} message 
when the « CALL-INFORIVIATION » method is used for conveying the line identifier information 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 


<ldentifiertype> 





Code for 'Line identifier' identifier type 


<ldentifier subtype> 





Code for 'Line identifier for external 
calls' subtype 


<ldentifier value> 


All 


The line identifier value itself 



pp 

attached to line u 



FP 



Network 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 



CC-INFO 



c< MULTI-KEYPAD, < Keypad info = 'called number' > » 



Use of line u 

for calling 

'called number' 




Figure 28: Line identification for a first external outgoing call, 
using the « CALL-INFORMATION » method 

NOTE: The Call Control message sequence in figure 28 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 



7.4.5.2.3 



Line identification for a //rsf external outgoing call using « MULTI-KEYPAD » 



This procedures applies to the FP and a PP effectively sending a line identifier for a first external outgoing call, using a 
«MULTI-KEYPAD» information element. 

When using the present procedure, a « MULTI-KEYPAD » information element shall be used for conveying the line 
identifier information. This information element shall be included either: 

• in the {CC-SETUP} message, as an addition to procedure "Outgoing call request" of GAP [12], clause 8.2; or 

• in a {CC-INFO} message, as described in procedure "Sending keypad information" of GAP [12], clause 8.10. 

In both cases, the following table shall be considered. 

NOTE: In the latter case, the «MULTI-KEYPAD» information element used may contain (partial or complete) 
called party number information. 

Table 20: Values used within the {CC-SETUP} or a {CC-INFO} message 
when the «MULTI-KEYPAD» method is used for conveying the line identifier information 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Multi-keypad» 


<Keypad info> 


23H 


Code for the pound key ('#') used for 
introducing the line identifier 


30H - 39H 


The line identifier itself 
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PP 

attached to line u e 1..9 



FP 



Network 



if CC-SETUP is used: 



CC-SETUP 



« IVIULTI-KEYPAD, < Keypad info = '23 3u'H > » 



if CC-INFO is used: 



CC-SETUP 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = '23 Su'H > » 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 



Use of line u 

for calling 

'called number' 




7.4.5.2.4 



Figure 29: Line identification for a first external outgoing call, 
using the « MULTI-KEYPAD » method 

FP managed line selection for a f/rsf external outgoing call 



This procedures applies to the FP and a PP making a first external outgoing call. It allows the PP not to send any line 
identifier for this new call. 

For a given call, it shall always be possible for a PP implementing the current procedure not to send any line identifier. 
In that case, the line selection is said to be "FP-managed". 

A FP implementing this procedure shall therefore always be prepared to possibly select a line on behalf of the PP. 

NOTE 1 : The PP can therefore allow its user not to select any line (either on a call-by-call basis, or permanently by 
configuration). 

NOTE 2: If the PP is attached to only one line (e.g. registered to a FP with only one line), it should not use the 

present procedure and send the line identifier in all cases, because FP management is not needed in that 
case (although it may send it without requesting the user to explicitly having to select the line). 

NOTE 3: A PP not implementing the "Line identification" feature (PPs compliant with NG-DECT Part 1 
(TS 102 527-1 [21]), GAP (EN 300 444 [12]) and PPs compliant with the present document not 
implementing the feature) also implicitly uses FP-managed line selection, but is out of scope of the 
present procedure. 

If the PP does not send any line identifier for a given outgoing call, the FP shall always notify back the PP of the used 
line identifier, even if there is only one line in the DECT system. This applies for the following types of PPs: 

• a PP implementing the present procedure; 

• an NG DECT PP not implementing the current procedure (a Part 1 PP, or possibly a Part 3 PP). 

A GAP PP however shall not receive any line identifier. 

The notified line identifier information shall be sent included in a « CALL INFORMATION » information element 
sent in a CC-INFO message. 
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< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 
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for calling 
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Figure 30: Line identification for a first external outgoing call, 
using the « CALL-INFORMATION » method 



Network 




7.4.5.3 



Line identification for external incoming call 



7.4.5.3.1 



General line identification requirements for external incoming calls 



For incoming calls, the "Line identification" feature enables the FP to notify the PP of the line on which the incoming 
call was received. 

NOTE 1: The current general procedure applies to all external incoming calls (first incoming call or waiting call). 
In the case of a waiting call, it applies conditionally to the implentation of the feature entitled "Common 
multiple call procedures". 

For incoming calls, the line identifier information shall always be sent included in a « CALL INFORMATION » 
information element, as follows: 

• For a first incoming call, it shall be sent in the CC-SETUP message, as decribed in clause 7.4.5.3.2. 

• For a waiting call, it shall be sent in every CC-INFO message used for notifying the waiting call, as decribed 
in clause 7.4.3.5.2. 



7.4.5.3.2 



Line identification for a //rsf external incoming call 



For incoming calls, the "Line identification" feature enables the FP to notify the PP of the line identifier of the line on 
which the incoming call arrived. 

A line identifier for an incoming call shall be sent from FP to PP in a «CALL INFORMATION» information element in 
the {CC-SETUP}message, as an addition to GAP [12], clause 8.12, "Incoming call request". 

The FP shall notify the line identifier used even if there is only one line in the system, and even if the PP is attached to 
only one line. 
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PP 

attached at least to 
line u 
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Network 



CC-SETUP 




Incoming call to line u 
from 'calling number' 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 



Figure 31 : Line identification for a first external incoming call 

7.4.5.4 Line specification in events notification 

This procedure applies to the FP and a PP implementing the "Generic events notification" procedure of clause 7.4.1 
(and including clause B.l). 

As an addition to the "Generic events notification" procedure of clause 7.4.1, a FP using the present procedure shall 
send a set a line identifiers along with the events notification. 

This set of line identifiers shall be sent in a «CALL-INFORMATION» information element, along with the 
«E VENTS -NOTIFICATION» information element in the same FACILITY message. For each of these line 
identifiers, the <Identifier typo field shall be "Line identifier" and the <Identifier subtype> field shall be "relating-to". 

NOTE 1 : The «CALL-INFORMATION» information element allows to send several identifiers of the same 
type and subtype. 

Such a set of line identifiers shall only be sent if at least one of the following conditions is fulfilled: 

1) The notification is broadcasted to all PPs, and every line in the set is concerned with all of the event types 
notified. 

NOTE 2: A simple way to achieve it is either to have the «E VENTS -NOTIFICATION» information element 
only contain a notification for a single type of event, or to have the set of lines reduced to a single line. 

NOTE 3: This condition allows a PP to ignore a notification that does not mention a line it is not attached to. 

Conversely, if a line is mentioned, all event types notified are relevant for this line. A PP can therefore 
always alert the user for an event type before querying the corresponding event list on the FP. 

2) The notification is only sent to PPs attached to all lines in the set (not excluding attachments to lines outside 
this set), and every line in the set is concerned with at least one of the events notified. 

NOTE 4: This condition ensures that a PP will never query an event list on the FP for nothing. It should however 
query the concerned event list before alerting the user for an event type, to be able to also notify the 
line(s) on which events of this type occurred. 
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attached to any line(s) 



FP 




Ongoing call (internal or external) 



FACILITY 




« EVENTS-NOTIFICATION : 
« CALL-INFORMATION, 



< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 



ifiertype = 'Line identifier' > 

ifier subtype = 'Relating-to line identifier' > 

ifier value = u > 

ifiertype = 'Line identifier' > 

ifier subtype = 'Relating-to line identifier' > 

ifier value = v > 



Figure 32: Events notification concerning lines u and v (example during a call) 

If a «CALL-INFORMATION» information element is used for conveying the set of lines concerned with the notified 
events as an addition to the "Generic events notification" procedure of clause 7.4.1, consider table 21. 

Table 21 : Values used within the {FACILITY} message 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-information» 






A line identifier is sent for each of the 
lines in the set 


<ldentifiertype> 





Code for 'Line identifier' identifier type 


<ldentifier subtype> 
<ldentifier value> 


3 


Code for 'Relating-to line identifier' 
subtype 


All 


The line identifier value itself 



7.4.6 Call identification 



7.4.6.1 



Call identifier general requirements 



Call identifiers are used to identify all ongoing calls in a DECT system, internal or external. They allow to enhance the 
"Parallel call" and "Multiple call" features. More specifically: 

• Call identifiers allow to properly handle PPs with more than 2 call instances, especially for all double call 
related procedures (see clause 7.4.3.5, "Common parallel call procedures (external or internal)"). 

• Even for PPs with only 2 call instances, call identifiers allow to properly handle asynchronous messages (for 
example a call toggle from the PP crossing a call release from the FP). 

Call identifiers are assigned by the FP and are uniquely defined DECT system- wide. In other words, call identifiers 
shall NOT be PP specific (i.e. there shall never be two equal call identifiers, even for 2 different PPs), nor line specific. 
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call-id = 4 (external) 




") line 1 
(external number 1) 



) line 2 
(external number 2) 



call-id = 2 (external) 



Figure 33: Calls identifiers are assigned by the FP and unique for the DECT System 

A call identifier is assigned each time a call is setup. In order to be usable for parallel/multiple calls, a call identifier 
shall be assigned also for the first call of a PP. 

The call identifier is freed at call release (i.e. available for a further new call). 

Typically, a FP will assign call identifiers by taking them in the 0..n interval, where 'n+V represents the maximum 
number of simultaneous calls the FP can handle. To assign a call identifier to a new call, it will use the smallest free 
number in this interval, free numbers being defined as not yet assigned numbers, or numbers that were assigned but for 
which the call has been terminated. 

Call identifiers shall be sent within the «CALL-INFORMATION» information element with <Identifier typo and 
<Identifier subtype> fields both equal to 'Call identifier'. It shall be sent in case the sending party (PP or FP) implements 
the "Call identification" feature. 

NOTE: The "Call transfer", "3-party conference with established internal and/or external calls" and "Call 

intrusion" features also make use of call identifiers with a different <Identifier subtype> = 'Updated call 
identifier', for the purpose of updating the identifier of an existing call. This subtype is not used within the 
"Call identification" feature itself 

Several procedures outside of the "Call identification" feature itself also use call identifiers conditionally to 
implementation of this feature. This includes some procedures of the "Common parallel calls procedures" feature. 

When implementing the feature, the PP shall set the corresponding terminal capability bit. 



7.4.6.2 



Call identifier assignment on outgoing call (FP to PP) 



The purpose of this procedure is to have the FP assign a unique call identifier for the call, external or internal, and 
notify it back to the calling PP. 

In case of internal call, the FP shall assign a single call identifier for both PPs. 

The assigned call identifier shall be notified back to the PP, by including a «CALL-INFORMATION» information 
element in a {CC-INFO} message with <Call identifier> field value equal to the assigned call identifier. 
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PP 



CC-SETUP 



CC-INFO 



FP 



Store call in call table 
and assign call id 



« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = '03'H > 
» 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 



Figure 34: Example of call identifier assignment on outgoing call, with call-id=3 

A service call (call with <Call class> equal to BH) shall also be assigned a call identifier. However, this call-id is 
intended for the first outgoing voice call placed within this service call, if any (e.g. a service call may be setup for 
accessing the contact list on the FP, which may be followed by an outgoing call setup within the same service call). 

7.4.6.3 Call identifier assignment on incoming call (FP to PP) 

The purpose of this procedure is to have the FP, upon incoming call, external or internal, assign a unique call identifier 
and send it to the PP. 

NOTE 1 : The "Handset locator" feature uses a kind of incoming call to which the FP also assigns a call identifier. 

In case of internal call, the FP shall assign a single call identifier for both PPs. 

A Call identifier for an incoming call shall be sent from FP to PP in a «CALL INFORMATION» information element 
in the {CC-SETUP}message. 

NOTE 2: The call identifier should not be displayed to the user. 

For this procedure using the {CC-SETUP} message, see table 22 of GAP [12], clause 8.12, "Incoming call request", 
with the additions described in table 22. 

Table 22: Values used within {CC-SETUP} 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Call-informatlon» 


<ldentifiertype> 


1 


Code for 'Call identifier' identifier type 


<ldentifier subtype> 





Code for 'Call identifier' subtype 


<ldentifier value> 


All 


The call identifier value itself 



PP 



FP 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = '02'H > 
» 



Figure 35: Example of Call identifier assignment on incoming call, with call-id = 2 
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7.4.7 Multiple lines handling 



7.4.7.1 



Multiple lines common requirements 



The "Multiple lines" feature describes the behaviour of DECT systems connected to more than one network lines. A PP 
registered in such a DECT system may be attached to one or several of these lines. 

The "Multiple line" feature is only useful if the DECT system is connected to at least two different lines. 



1 PP attached to the 
PSTN line 

3 PPs attached to 

the VoIP line 1 

(Residential use) 



2 PPs attached to the — 
VoIP line 2 
(Home Office) 




-^ 



PSTN line 
"^ (external number 1) 



VoIP line 1 -Residential use 
_ Q ) (external number 2) 



VoIP line 2-Home Office 
Q ■) (external number 3) 



Figure 36: Example of a multiple line configuration with 3 lines (with attachments) 
PPs attached to several lines are hatched 

When implementing the "Multiple lines" feature, the PP shall set the corresponding terminal capability bit. The FP shall 
set bit 333 of the "Extended higher layer capabilities (part 2)" (see EN 300 175-5 [5], clause F.3). 

7.4.7.1.1 Pre-requisites 

The following pre-requisites for implementation of the "Multiple lines" feature shall be taken into account: 

• A FP implementing the "Multiple lines" feature shall implement the "Line identification" feature as a 
pre-requisite. 

• A PP implementing the "Multiple lines" feature should implement the "Line identification" feature as well. 

• A PP or FP implementing the "Multiple lines" feature shall implement the feature entitled "Common parallel 
call procedures" of clause 7.4.3.5 as a pre-requisite, so that a new call on a different line can be placed or 
received on an already in use handset. 



7.4.7.1.2 



Minimum requirements 



An implementation of the "Multiple lines" feature on a DECT system shall comply with the following minimum 
requirements: 

• The "Maximum number of simultaneous calls" supported by a FP implementing the "Multiple lines" feature 
shall be at least equal to 2. This includes support of as many simultaneous call contexts. 



7.4.7.2 



Terminal attachment and line settings 



All registered PPs shall be attached to at least one line. A PP may be attached to one or more lines. For example, a given 
PP can be attached to a PSTN line and a VoIP line at the same time. 
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7.4.7.2.1 Initial attachment 

The FP shall provide at least one of the following two possible attachment modes: 

FP-managed attachment: After subscription registration the PP is attached by the FP to one or several lines with no 
specific user intervention. 

In case of FP-managed attachment, and in order to know the set of lines it is attached to, the PP may read the "Attached 
handsets" setting of all "Line settings" entries via the "List access service" feature (NG1.N.16). 

PP-managed attachment: Attachment is initiated by the PP during or just after subscription registration. 

An initial PP-managed attachment shall be implemented as an update of the "Attached handsets" setting for every entry 
in the "Line settings" list corresponding to a targeted line, and performed via the "List access service" feature 
(NGLN.16). 



7.4.7.2.2 



Attachment modification 



The PP should be able to change the initial attachment (add or remove lines) during or after location registration. If 
supported, the PP shall initiate the procedure. 

An attachment modification shall be implemented as an update of the "Attached handsets" setting for every entry in the 
"Line settings" list corresponding to a targeted line, and performed via the "List access service" feature (NGLN.16). 

7.4.7.2.3 Line settings 

The FP shall support the "List access service" feature (NG1.N.16) and the "Line settings" list. 

Apart from the "Attached handsets" setting itself, a PP shall only be able to update the settings of the lines it is attached 
to. 



7.4.7.3 



Incoming and outgoing external calls on a multiple line system 



This procedure applies to the FP and a PP attached to one or more line(s). If the PP is idle, or in communication on the 
same line, no specific requirement is needed. Conversely, if the PP is already in communication on another line, 
specific requirements are needed. The following table details the procedures to be used. 

Table 23: Incoming and outgoing external calls on a multiple line system 





Incoming call on line A 


Outgoing call on line A 


All idle PPs 


Usual "mono-line" requirements apply 
(see notes 1 and 2) 


Usual "mono-line" requirements apply 
(see notes 1 and 2) 


All PPs attached to line A 
in communication on line A 


All PPs attached to line A and B 
in communication on line B but not A 
(parallel incoming or outgoing call on 
another line A; see note 3) 


"Call waiting indication (external or 
internal)" (clause 7.4.3.5.2), shall be 
used (see note 1 ) 


"Outgoing parallel call initiation" 
(clause 7.4.3.5.1) shall be used (see 
note 1) 


NOTE 1 : In any case, "Line identification" must be used on FP side, and should be used on PP side. 

NOTE 2: The new call on line A may be a first call or a parallel call. If the line A is a multiple call line, please refer to 

clause 7.4.8.2, "Incoming and outgoing external calls on a multiple call line"; otherwise, usual procedures 

defined in the present DECT standard apply. 
NOTE 3: In this case, the PP is necessarily attached to several lines (at least A and B). The PP is busy with line B but not 

A, which means that with regards to line A it is not involved in any call. However, as it is not idle, parallel call 

procedures apply (feature "Common parallel call procedures" of clause 7.4.3.5). 



7.4.7.4 Internal calls in multiple line context 

This procedure applies to the FP and a PP attached to one or more line(s). 

Internal calls in multiple line context shall be possible between any two PPs, even if there is no line to which both PPs 
are attached. 
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It should be possible to forbid internal calls between PPs that do not share a common line by configuration of the DECT 

system. 

7.4.7.5 Compatibility with non multiple line PP or FP 

This procedure applies to a non multiple line DECT equipement (PP or FP) in front of a DECT-NG PART3 PP or FP 
implementing the "Multiple lines" feature. 

Non multiple line DECT equipment include: 

• NG DECT Part 3 PP or FP, not implementing the "Multiple Unes" feature. 

• NG DECT Part 1 PP or FP. 

• GAP PP or FP. 

NOTE: For a PP, not implementing the "Multiple lines" feature does not necessarily mean that the PP is attached 
to only one line; is only means that the PP is not aware of possible multiple attachments. 

7.4.7.5.1 Non multiple line PP in front of a multiple line FP 

Attachment: A non multiple line PP shall use FP-managed attachment and is not aware of the lines it is attached to 
(only the user is). 

NOTE: A FP should not attach a PP to more than one line if the PP does not implement the "Multiple line" 

feature but however implements the "List access service" feature (NG1.N16) and the "Line settings" list. 

Outgoing calls: A non multiple line PP may: 

• Either use FP-managed line selection; in that case, if the PP is a non GAP PP and implements the "Line 
identification" feature, it should use the line identifier notification received to notify the user of the line used. 

• Or use the '#' key based line selection mechanism of clause 7.4.5.2.3 ("Line identification for a first external 
outgoing call using «MULTI-KEYPAD»"). In that case, the user must manually enter the line identifier 
after the '#' key. 

Incoming calls: A non multiple line PP shall receive all incoming calls arriving on one of the lines it is attached to; if 
the PP is a non GAP PP and implements the "Line identification" feature, it should however use the line identifier 
received to notify the user of the line used. 

7.4.7.5.2 Non multiple line FP in front of a multiple line PP 

In front of a "non multiple line" FP (hence connected to at most one line), a PP implementing the "Multiple lines" 
feature is however attached to a single line. 

• In front of a non-GAP FP, it should send the corresponding line id for each call, as specified in clause 7.4.5.2.2 
(or alternatively clause 7.4.5.2.3), and not use "FP-managed line selection" (following the recommendation 
included in clause 7.4.5.2.4 that FP-managed line selection is not meant for PPs attached to a single line). 

• In front of a GAP FP, it shall not send any line identifier. 

7.4.8 Multiple call line handling 
7.4.8.1 Multiple calls general requirements 

The "Multiple calls" feature represents the ability for a FP and PP to support several fully parallel calls (outgoing or 
incoming) to and from a single line supporting the "Multiple call" mode. 
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a line 
a single external number) 



Figure 37: A multiple-call line with three simultaneous calls 

This feature is especially useful when several calls are placed or received on different handsets at the same time. 
However, a multiple call enabled DECT system is compatible and can be connected to a non multiple call line like a 
PSTN line. 

From the DECT system point of view, a multiple call line may be configured in "single call" mode. To configure a 
multiple call line in "single call" mode, or the other way round, the "Multiple call mode" setting of the "DECT system 
settings list" (see clause 7.4.11.4.8) shall be used through the "List access service" feature (NG1.N.16). 

NOTE 1 : PSTN double calls are also a kind of multiple calls on a single line, but always with a single handset for 
both calls, and only one call context active at a time. 

NOTE 2: "Multiple calls" is most notably a feature brought by VoIP protocols, allowing several call contexts to be 
opened simultaneously on network side. 

When implementing the "Multiple calls" feature, the FP shall set bit a39 of the "Extended higher layer capabilities 
(part 2)" (see EN 300 175-5 [5], clause F.3). 

7.4.8.1.1 Pre-requisites 

The following pre-requisites for implementation of the "Multiple calls" feature shall be taken into account: 

• A FP implementing the "Multiple calls" feature shall implement the "Call identification" feature as a 
pre-requisite. 

• A PP implementing the "Multiple calls" feature should implement the "Call identification" feature as well. 

• A PP or FP implementing the "Multiple calls" feature shall implement the feature entitled "Common parallel 
call procedures" of clause 7.4.3.5 as a pre-requisite, so that a new call can be placed or received on an already 
in communication PP. 

NOTE: On FP side, implementation of the feature entitled "Common parallel call procedures" also implies 
implementation of the "Line identification" feature. 



7.4.8.1.2 



Minimum requirements 



An implementation of the "Multiple calls" feature on a DECT system shall comply with the following minimum 
requirements: 

• The "maximum number of simultaneous calls" supported by a FP implementing the "Multiple calls" feature 
shall be at least equal to 2. This includes support of as many simultaneous call contexts. 

• The FP shall be able to support this maximum number of incoming or outgoing calls for idle PPs as defined in 
clause 7.4.6.2. This includes simultaneous ringing of all idle PPs on incoming calls and availability of all idle 
handsets for placing a new call when there is already a call going on on the line. 
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7.4.8.2 



Incoming and outgoing external calls on a multiple call line 



This procedure applies to the FP and the PP at external call (incoming or outgoing) setup on a multiple call line. This 
line might be set in "multiple call" or "single call" mode. 



7.4.8.2.1 



Line set in "single call" mode 



On a multiple call line configured in "single call" mode, only one call can be active at a time on the line. Other calls 
(second, or further) are on-hold and can only become active by replacing the existing one on the same PP. 

To handle a line in "single call" mode, the DECT system shall use the usual procedures defined in the present DECT 
standard. In particular, the feature entitled "Common parallel call procedures" shall be used to handle the second or 
further call on the same PP. 

If the DECT system is busy, but implicit call intrusion is enabled by configuration, clause 7.4.3.8.1 shall be used instead 
of the "Busy system or line notification" procedure (clause 7.4.6.3). 



7.4.8.2.2 



Line set in "multiple call" mode 



On a multiple call line configured in "multiple call" mode, several calls may be active simultaneously; second and 
further calls are presented to all PPs (idle or busy). The following table details the procedures to be used. 

Table 24: Line set in "multiple call" mode 





Incoming call setup 


Outgoing call setup 


On all idle PPs 
attached to the line 


GAP 8.12 "Incoming call request" shall be used 
(see note 1) 


GAP 8.2 "Outgoing call request" shall be used 
(see note 2) 


On all busy PPs 
attached to the line 


"Call waiting indication" (see clause 7.4.3.5.2), 
shall be used (see notes 3, 4 and 5) 


"Outgoing parallel call initiation" 

(clause 7.4.3.5.1) shall be used (see notes 2 

and 3) 


NOTE 1 : Unless the DECT system is busy (see clause 7.4.6.3), although the line was not, in which case the call is 

not presented. 
NOTE 2: If the DECT system is busy, the "Busy system or line notification" procedure (see clause 7.4.6.3) must be 

used back. 
NOTE 3: All "Common parallel calls procedures", then, apply for handling the parallel calls. The fully parallel calls 

are in this case only alternatively active as for PSTN double calls. 
NOTE 4: On a multiple call line with VoIP interfacea call waiting procedure for already in use handsets may be used 

in the following two cases: a second VoIP call is received, or an in-band call waiting tone from a PSTN to 

VoIP gateway is received. However, the used procedures are the same. 
NOTE 5: If the call is meanwhile accepted by another PP, or if the remote party hangs up before the call is accepted 

by any PP, the call must be then released by the FP towards the current PP (see clauses 7.4.3.5.4 and 

7.4.3.5.5). 



7.4.8.3 



Busy system or line notification 



This procedure applies to the FP and a PP that initiated an outgoing call (external or internal) at a point in time where 
the FP and/or the line cannot support the additional call. The new outgoing call may be a first call, or a parallel call. 

NOTE 1 : The current procedure applies within an outgoing call setup attempt. For idle PPs, a «DISPLAY» 

notification can also be used outside of any call for preventing call setup attempts, especially on a line in 
single-call mode. 

NOTE 2: In single call mode, the line is considered busy for idle PPs, as soon as one call is going on on it. 

Busy line: A busy line is a line for which no new incoming or outgoing call can be performed, because all of the 
available bandwidth is used. This concept is especially relevant for multiple call lines. 

Busy system: A DECT system is busy if the FP is not able to support any additional call, because the maximum 
number of call contexts it can handle has been reached. The system may be busy without the line being busy. 

NOTE 3: A call context could be used by an internal call. A system should allow as many calls (external or 
internal) as there are call contexts potentially available on the system. 
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On call setup attempt (first or parallel), if the system is busy or the line is busy, the FP shall send back a "busy system 
or line notification" back to the PP, in the form of a «SIGNAL» information element with <Signal value> field equal 
to 04H ('busy tone') included in a CC-INFO message. 

If the PP does not hook on after a time-out has elapsed, the FP shall send a call release request to the PP to terminate the 
call attempt. This call release request shall take the form of a CC-RELEASE message for a first call, or of a CC-INFO 
message according to procedure "Call release and call release rejection" (clause 7.4.3.5.4), for a parallel call. 



PP 

attached to 
a multiple-call line 



Added in case the call-id was assign 
before the busy status of the line 
was discovered (see note 4) 



fed 



FP 



the FP and/or the multiple call line 
cannot support the additional call: 



CC-INFO 



« SIGNAL, < value = 'busy tone' = 04'H > » 

« CALL-INFORIVIATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = '03'H > 



Call release request 



After some 
time out 



Figure 38: Busy system or line notification for call with defined call-id=3 

NOTE 4: The call identifier may be sent here even if the PP did not receive it before. Ignored on PP side, if the PP 
does not implement the "Call identification" feature. 

7.4.9 PP and FP capabilities indication and broadcast 
7.4.9.1 Terminal capability indication 

NOTE 0: This procedure description replaces clause 8. 17 of EN 300 444 (GAP) [12]. 

The PP shall be able to send the «Terminal capability» information element and the FP shall be able to receive it at 
least in {ACCESS-RIGHTS-REQUEST} and when location registration is supported in the {LOCATE-REQUEST}. 
The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

Table 25: Values used within the «TERMINAL CAPABILITY» information element 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal 
capability» 


<Tone capability> 


All 




<Display capability> 


All 


If PI supports feature (GAP.N.24) it 
shall indicate in this field value which 
is equal to or higher than 2 


Echo parameters 


[1,2,31 


See note 1 








Slot type capability 


All 


Full and long 640 slots mandatory; 
double and long 672 optional. See 
also note 2 


Ambient noise Rejection 
(N-REJ) 


[1,2] 


See note 2 


Adaptive volume control 
(A-VOL) 


[1,2,3] 


See note 2 


<Profile indicator 1> 


"xxxxxl x"B 


GAP and/or PAP supported 
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Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 




<Profile indicator_6> 


"1xxxxxx"B, "Oxxxxx"B 


Support (or not support) of "no- 
emision" mode (optional feature) 


<Profile indicator_7> 


"xxxx11x"B 


New Generation DECT Wideband 
speech supported, and Part 3 
supported. 




"xxx1xxx"B or "xxxOxxx"B 


Support of tlie "Call identification" 
feature [NG1.N. 13] 




"xx1xxxx"B or "xxOxxxx"B 


Support of the "Common parallel call 
procedures" feature [NG1 .N.7] 




"xlxxxxx" or "xOxxxxx"B 


Support of the "IVIultiple lines" feature 
[NG1.N.14] 


<Control codes> 


All 


If PT supports feature (GAP.N.25) it 
shall indicate in this field value which 
is equal to or higher than 2 



NOTE 1: Echo parameters values "01" and "10" may only be set by type 2a PPs. See clause 6.8, table 7, note 2 for 
restrictions on PPs type 2a. GAP compliant or NG-DECT part Icompliant PPs may also set these values. 

NOTE 2: This capability is assumed as the default value (see table 26) if the «TERMINAL-CAPABILITY» 
information element is omitted. 

The capabiUties in table 26 shall be assumed as default if the following fields in the «TERMINAL CAPABILITY» 
information element are not present. 

Table 26: Values assumed as terminal capabilities 



Information element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal capability» 


<Echo parameters> 


1 


Minimum Telephone Coupling 
Loss (TCL) (> 34 dB) 


<N-REJ> 


1 


No noise rejection 


<A-VOL> 


1 


No PP adaptive volume control 


<Slot type capability> 


"xxx1x1x"B 


Full slot and Long slot (j=640) 
supported 



No echoing of characters is allowed in the FT and therefore the PT would be responsible for displaying dialled digits. 
All display information from the FT would be assumed to be additional information that the PT shall display in 
addition. The PT shall logically separate display information originating at the FT and PT. This could be achieved, for 
example, by one physical display and two logical displays or two physical displays and two logical displays. The key 
point is that display characters from the PT and FT shall not be simultaneously interleaved/mixed on the same physical 
display. 



7.4.9.2 



Higher layer information FP broadcast 



The FP and PT shall support the broadcast of Higher Layer capabilities as part of Qx MAC broadcast messages (see 
clauses 7.6.3, 7.6.4 and 7.6.5). 

The broadcast attributes are a small set of NWK layer and DLC layer capabilities (jointly known as "higher layer 
capabilities") that shall be broadcast regularly as part of the MAC layer broadcast service. See EN 300 175-5 [5], 
annex F. 

RFPs belonging to the same LA shall broadcast the same values of higher layer attributes (see EN 300 175-5 [5], 
annex F) at any given time. 

The PP shall be capable to read and interpret at least the following broadcast attributes codings during locking 
procedure. In the locked state the PP may assume them as static. 

FP and PT shall support the following values of "Higher Layer capabilities" information attributes. 
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7.4.9.2.1 Higher layer information in standard FP broadcast (Qh= 3) 

The requirements of clause 7.3.9.1 of TS 102 527-1 [21] shall apply. 

7.4.9.2.2 Extended Higher Layer capabilities part 2 

The Extended Higher Layer capabilities, part 2, Fixed Part Information field shall be used indicating the supported set 
of Wideband speech Services. 

Table 27: Extended Higher Layer Capabilities part 2 interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


<a24> 


NG-DECT Wideband voice 
supported 


1 


See TS 102 527-1 [21] 


< 829 > 


NG-DECT extended voice 
supported 


1 




030 > 


NG-DECT extended voice 
supported sets of services: 
Call transfer (external or 
internal) 


[0,1] 


Related procedures: clause 7.4.3.6 


<a3i> 


NG-DECT extended voice 
supported sets of services: 
Common parallel call 
procedures (internal or 
external) 


[0,1] 


Related procedures: clause 7.4.3.5 


<a32> 


NG-DECT extended voice 
supported sets of services: 
Third party conference call 
(internal or external) 


[0,1] 


Related procedures: clause 7.4.3.7 


<a33> 


NG-DECT extended voice 
supported sets of services: 
Intrusion call 


[0,1] 


Related procedures: clause 7.4.3.8 


<a34> 


NG-DECT extended voice 
supported sets of services: 
Call deflection 


[0,1] 


Related procedures: clauses 7.4.4.1.1 and 7.4.4.2 


<a35> 


"no emission" mode support 


[0,1] 


Related procedures: see NG1.M.5 in clause 6.12 


<a36> 


List access service feature 
support 


[0,1] 


Related procedures: clause 7.4.10 


<a37> 


Easy pairing feature support 


[0,1] 


Related procedures: clauses 7.10.1.2.1, 

7.10.1.3.1, 7.10.1.2.2, 7.10.1.2.3, 7.10.1.3.2 and 

7.10.1.3.3. 

If supported, for security reasons, it shall be set to 

"1 " and unset at the same time as a44 


<a38> 


Multiple lines 




Related procedures: clause 7.4.7 


<a39> 


IVIultiple calls 




Related procedures: clause 7.4.8 


<a4o> 


Permanent CLIR 




Related procedures: clause 7.4.12 



7.4.10 List access service 



7.4.10.1 



General considerations 



Equipment supporting New Generation DECT Part 3 shall support the "List access service" feature as described in the 
present clause. The lists managed by this feature are structured as represented in figure 39. 
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Contact 

list 



. name 
. first name 
. contact 
number 
. associated 
melody 



n entries 



Internal names 
list 



number 
name 
Line name 
Line id 



n entries 



User data oriented lists 



etc. 



DECT system 
settings list 



. FP registra- 
tion mode 
. PIN code 
. clock master 
. Base reset 
. FP IP 
address 
. FP version 



1 entry 



Line settings list 



Line id 
Line name 
attached PP 
dialling prefix 
FP melody 
FP volume 
blocked nb 
multiple calls 



m entries (1 entry per line) 



DECT system and line settings lists 



list access 

Figure 39: Structure of the lists managed by the "List access service" feature 

The list access feature defines a generic way to access lists located in the FP from the PP. This access includes 'read', 
'edit' and 'delete' functionalities. 

When implementing the feature, the FP shall set the capability bit indicating "List access service" feature support (see 
EN 300 175-5, [5], clause F.3, bit a36). 

The procedure is based on IWU-Info messages, which contain the information element «IWU to IWU», using the 
dedicated protocol discriminator '03'H. 

Table 28: Values used within the «IWU to IWU» information element 



Information element 


Field within the Information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


L 


Length of content 


<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


03H 


List access 


<Command > 


1...127 


List access command 


<Command specific byte 0> 












<Command specific byte L-2> 







Basic service : 

The procedure can be started by a PP either in idle mode or in an already existing call. The procedure can be used 
independently of the basic service <Call class> field value of the call (i.e. all lists may be accessed with any <call class> 
value). 

At call setup, it is recommended to use the following value for the <Call class> field of the «Basic service» IE: 

• 'Internal call setup' for access to the list of internal names. 

• 'Normal call setup' for access to the missed calls list, outgoing calls list, all calls list, incoming call accepted 
list, and contact list. 

• 'Service call setup' for access to the system settings list and the line settings list. 

If a call is already setup (internal or external call), the system shall continue to use the same connection for the list 
access session. 

NOTE 1: Before starting the list access session, the PP may put the existing call on-hold (see clause 7.4.3.5.8) to 
indicate to the FP that the speech path is suspended during the list access session. 
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Interactions with incoming or outgoing voice call: 

When initiating a list access session when a voice call (internal or external) is already ongoing. The PP: 

• May put the existing call on hold (see clause 7.4.3.5.8) prior to list access. 

• However, if the list access session is intended to establish an other voice call, the PP shall either: 

Put the first voice call on hold prior to the list access session (see clause 7.4.3.5.8). 

Use the outgoing parallel call initiation procedure (see clause 7.4.3.5. 1) and access the list within this 
new call. 

When initiating a voice call during a list access session: 

• If the <Call class> is Internal call setup', and the call is a first call, dialled digits shall be used for placing an 
internal call. If the call is a parallel call, the NG1.N.7 "Common parallel calls procedures" feature shall be used 
instead. 

• If the <Call class> is 'Normal call setup', and the call is a first call, dialled digits shall be used for placing an 
external call. If the call is a parallel call, the NG1.N.7 "Common parallel calls procedures" feature shall be 
used instead. 

• If the <Call class> is 'Service call setup', dialled digits are for external call; unless the 17H 'Internal call' 
control code is send before the dialled digits. There will be an implicit change of the call class: the system will 
act as if the call class had changed from 'Service call setup' to 'Normal call setup' or to 'Internal call setup' as 
appropriate for the voice call being initiated. 

When receiving an incoming voice call during a list access session, the FP may either: 

• Close the list access session, release the list access call, and then present the incoming call as a first call using 
a new connection. 

• Close the list access session, and manage the incoming call as a parallel incoming call (or "waiting call"; see 
NG1.N.6 "Parallel Calls" and related NG1.N.7 "Common parallel calls procedures" features). 

• Leave the list access session open in the current state, and manage the incoming call as a parallel incoming 
call. 

NOTE 2: When a connection has been setup for a list access session, a waiting call may be the first voice call 

occurring during the connection (i.e. it is not a truly parallel call although the "Waiting call indication" 
procedure is used). 

When an open list access session and a voice call(s) are ongoing in parallel, the FP shall not release the link before the 
session and the call are ended. 

Interactions with the "Call identification" feature NG1.N13: 

Assuming that the "Call identification" feature NG1.N13 is implemented on FP side, call identification is intended for 
voice calls only. More specifically: 

• At list access call setup, whatever the call class, the FP shall assign a call id just after the SETUP message. 
This call-id is intended for the outgoing voice call expected to be placed following the list access session. 

• If list access re-uses an already established connection, no call identification shall be assigned by the FP at list 

access session setup. 

• When the PP initiates a first voice call during a list access session, the voice call shall use the already assigned 
call identifier. 

• When the PP initiates a parallel voice call during a list access session (the list access session was started while 
a first call was going on), the FP shall assign a new call id to this parallel call. 

• When a waiting call is presented during a list access session, the FP shall always assign a new call-id to this 
incoming call. In other words, even if this waiting call is the first voice call occuring within the connection, it 
shall never use the already assigned call id. 
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Moreover the use of the Cp channel is recommended in case both parties support it (indicated in FP capabilities, 

bit a26). If there was an existing call when the list access session is started, the PP shall first put the existing call on- 
hold (see clause 7.4.3.5.8) before using the Cp channel. 

Access to a list is encapsulated in a session. Each session is linked to exactly one list access and is used: 

• by the FP to grant access to a list; 

• to handle accesses to multiple lists from one PP. 

Typical sequences of commands between start and end of a session are the following: 

• "Read entries" or "search entries", for just reading entries; 

• "Read entries" or "Search entries" followed by "Edit entry" and "Save entry" for updating an existing entry, if 
an "Edit entry" has been issued but the list entry is left unchanged, a "Save entry" command shall still be used 
to unlock the entry; 

• "Save entry" with entry id equal to 0, for creating a new entry in the list. 

Entry identifier: Each entry in a list is unambiguously identified within the FP for a dedicated list by an entry id. This 
entry id has to be referenced in case of writing access and is used by the FP to reject multiple write accesses from 
several PPs. 

Field identifier: Each entry of a list may contain several fields. Each field has a unique identifier which is list 
dependent (see clause 7.4.10.5). This means the same field may be included in several list but with a different field id. 
This shall be taken into consideration when using field id in a command. 

List index: The list index determines the position of an entry in a sorted list and is used for navigation within a list. The 
list index may change after modification of the list. 

In order to indicate list changes to the PPs, a notification procedure is defined. This enables the PP to read list contents 
in advance before using them (caching), enabling the PP both to hold local copies of lists and to anticipate operations 
around the current entry, in order to save time and so increase interactivity (faster MMIs on PP side). 

List entry fields with characters shall in the FP be stored in UTF-8 format. PP shall be able to support at least IA5. 

Guarantee of service: 

When the FP supports a list, it shall manage and process all mandatory commands. Negative answers are allowed only 
for real faulty cases and shall not be used systematically. Especially, the FP shall not declare it supports a list and 
respond with negative answers to all commands. 

When the FP supports a list, it shall support as many fields as possible. 

When the FP supports a field of an entry, it shall support as many values as possible for the field and process this field 
correctly. For example: if the FP uses a name entry field it shall fill it correctly and not always leave it empty. 

When the DECT-NG PART3 system supports a list, it shall also implement the corresponding service related to this list, 
entry or field. The PP shall display as many fields as possible. For example: if a FP declares a contact list, the FP shall 
fill it correctly and support all mandatory requests from all PPs. The PP shall provide access to this contact to the user 
and not re-create a local copy of the list. 

Of course the FP shall update automatically missed calls, outgoing call, all call list by adding locally corresponding 
entries in the lists. 

Initial values: 

• First possible session identifier assigned by FP shall be "1". Value "0" is a reserved return value used by the 
FP when a problem occurs. 

• First possible "list identifier" shall be "0" (see clause 7.4.10.3 for list identifier coding). 

• First possible "entry identifier" assigned by FP shall be "1". 

• First possible "field identifier" shall be "1". 
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• First possible "Start index" parameter value in read/read confirm/search entries/search entries confirm 
commands shall be "1". Value "0" points to the last entry. 

• First possible "position index" parameter value in save/save confirm commands shall be "1" (first entry). 
Value "0" points to the last entry. 

Sessions: 

The FP shall be able to handle 2 started sessions initiated from a single PP at the same time. 

All sessions between a PP and FP are ended at the latest at call release. 

The number of entries allowed within a list is defined by the FP (manufacturer dependent). A dedicated error code shall 
be used if PP tries to save new entry in a full list. 

7.4.1 0.2 List change notification 

When a list change notification is implemented by the FP: 

• The notification shall be sent upon change of the contents of a list (i.e. change of an entry or addition of an 
entry). 

• If the list contains a line identifier, the notification shall be sent to all PPs attached to line id of the modified 
entry, and only to them. 

• If the list does not contain any line identifier, the notification shall be sent to all registered PPs. 

• Notifications shall be sent by the FP by use of the "generic event notification" procedure. For indication of list 
change and values used in «Events notification» information element, consider table 29. 

Table 29: Values used within {FACILITY} message for list change indication 



Information element 


Field within the Information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 


<Event type> 


3 


List change indication 


<Event sub typo 


X 


List identifier as indicated in 
clause 7.4.1 0.3 


<Event multiplicity > 


0..127 


Total number of entries in the list 
(see note) 


NOTE: 'Event multiplicity' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 



In order to allow the display of information in idle mode on PP side, notifications shall be sent by the FP for: 

• Line settings list. 

• Internal names list. However, a change in this list shall only be notified when a PP modifies the name of 
another PP (if the FP allows it), and the list change notification shall only be sent to that other PP concerned by 
the change. 

For all other lists, sending of notifications is left free to the implementor. However, the possibly important extra 
processing on FP and PP sides necessary for sending and handling notifications (e.g. if sent for each call) shall be 
carefully taken into account. 

NOTE: If the corresponding feature is implemented, the notification includes the CALL INFORMATION IE with 
line identifier. This might be useful when notifying a change in the line settings list. 
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7.4.1 0.3 List identifier codings 

The following list identifier codings are defined: 



Bits 87654321 



Meaning 



00000000 
00000001 
00000010 
0000001 1 
00000100 
00000101 
000001 10 
000001 1 1 
00001000 
1 xxxxxxx 



List of supported lists 
Missed calls list 
Outgoing calls list 
Incoming accepted calls list 
All calls list 
Contact list 
Internal names list 
DECT system settings list 
Line settings list 
Reserved for proprietary lists 



all other values reserved 
The lists shall be sorted on the FP, using default criteria for each of them. The default sorting criteria are the following 

• The "Missed calls", "Outgoing calls", "Incoming accepted call" lists, and more generally all call-related lists 
shall be sorted by default using the "Date and time" field. 

• The "Contact" list shall be sorted by default using the "Name" field (first criterion). In case the names are 
equal the list should be sorted using the "First name" field (criterion 2). 

• The "Internal names" list shall be sorted by default using the "Number" field (terminal id number). 

• The "Line settings" list shall be sorted by default using the "Line id" field. 

Please refer to the "Start session" command for a definition of the sorting order used for a given field type (this 
definition applies independently of the position of the field in the sorting process: i.e. whether used as "first criterion", 
"criterion 2", etc.). 



7.4.10.4 



List Access Commands 



The following list access commands are defined: 



Bits 87654321 


Meaning 


PP -> FP 


FP -> PP 


00000000 


start session 


yes 


- 


00000001 


start session confirm 


- 


yes 


00000010 


end session 


yes 


yes 


0000001 1 


end session confirm 


yes 


yes 


00000100 


query supported entry fields 


yes 


- 


00000101 


query supported entry fields confirm - 


yes 


000001 10 


read entries 


yes 


- 


000001 1 1 


read entries confirm 


- 


yes 


00001000 


edit entry 


yes 


- 


00001001 


edit entry confirm 


- 


yes 


00001010 


save entry 


yes 


- 


0000101 1 


save entry confirm 


- 


yes 


00001 100 


delete entry 


yes 


- 


00001 101 


delete entry confirm 


- 


yes 


00001 1 10 


delete Hst 


yes 


- 


0000 1111 


delete list confirm 


- 


yes 


00010000 


search entries 


yes 


- 


00010001 


search entries confirm 


- 


yes 


00010010 


negative acknowledgement 


- 


yes 


0001 001 1 


data packet 


yes 


yes 


00010100 


data packet last 


yes 


yes 


Ixxxxxxx 


reserved for proprietary list access 


commands 




all other values reserved 







Proprietary list access commands shall have list access command codings with most significant bit set to '1' 
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The "read entries", "read entries confirm" and "search entries confirm" commands use a start index as these command 
may apply to a range of entries within a Hst. 

The "save entry" and "save entry confirm" commands use a position index as these commands apply to one entry. 

Possible error codes are specified for each command from PP to FP. They use negative acknowledgement command, 
with exception of negative start session confirm. 



7.4.10.4.1 



Start and end session 



7.4.1 0.4.1 .1 "Start session" command 

This command from PP requests to start a session to access the specified list in the FP. 

Table 30: Values used within {IWU to IWU} information element 
to request the starting of a list change session 



Information element 


Field within the Information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =start session> 





List access command 


<List identifier> 


O..FFH 


List identifier 


<Sorting fields> 




List of suggested fields for sorting 
the list towards this PP 


<Number of sorting fields> 


0..255 


If 0, the default sorting of the list shall 
be used by the FP (see note) 


<Sorting field identifier 1> 


0..255 


Suggested field element type used 
for sorting the list (first criterion) 








<Sorting field identifier n> 


0..255 


Suggested field element type used 
for sorting the list, to be used when 
field 1, ... , field n-1 of both 
compared entries are equal 
(criterion n) 


NOTE: It is recommended to limit the number of requested sorting fields to two (n=2). 



The submitted sorting field identifiers suggest entry fields which should be used by the FP to sort the requested list 
towards this PP in the given session. This suggests to sort the list by "sorting field 1" as first criterion, and then by 
"sorting field 2" as second criterion, when field 1 of both compared entries are equal, and so on. 

For each field type, a sorting order is defined, which applies independently of the position of the field in the sorting 
process: i.e. whether used as "first criterion", "criterion 2", etc. The defined sortings are as follows: 

• For fields of type "Number" (including terminal id numbers), "Name", "Line name", "First name", or "Contact 
number", the alphanumerical order shall be used. 

NOTE: The alphanumerical order can only be defined on a subset of the UTF-8 encoded characters. This subset 
and the associated order depend on the locale used. 

• For fields of type "Date and time", the ante-chronological order shall be used (highest index for the oldest call, 
lowest index for the newest call). 

• For fields of type "Line id", the ascending numerical order shall be used. 

If the <Number of sorting fields> is equal to 0, the FP shall use the default sorting of the list. No sorting field identifier 
is sent in this case. 
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7.4.1 0.4.1 .2 "Start session confirm" command 

This command from FP to PP confirms or rejects the start of the session. 

Table 31 : Values used within {IWU to IWU} information element to confirm or 
reject the starting of a list change session 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =start session 
confirm> 


1H 


List access command 


<List identifier> 


O..FFH 


List identifier 


<Session identifier> 


0..127 


Session identifier (see note 1) 


<Total number of available 
entries> 


0..127 


Number of available entries in list 
requested by the PP (see note 1) 


<DiscrJminator typo 


OOH, 01H 


Undefined, EMC (see note 2) 


<DiscrJminator> 


OOH..FFH 


EMC value high byte 


<Discriminator> 


OOH..FFH 


EMC value low byte 


<Start session reject reason> 


O..FFH 


Reject reason in case of reject 


<Sorting fields> 




List of fields used for the actual 
sorting the list towards this PP 


<Number of sorting fields> 


0..255 




<Sorting field identifier 1> 


0..255 


Field element type used for the 
actual sorting the list (first criterion) 








<Sorting field identifier n> 


0..255 


Field element type used for the 
actual sorting of the list (criterion n). 


NOTE 1 : Total number of available entries' and 'session identifier' can be extended using the most significant bit up 
to 16383. In case more than one byte is used for the value, the highbyte shall be send before the lowbyte 
(e.g. '1 ' is coded as 0x81 , '1 28' is coded as 0x01 0x80). 

NOTE 2: Discriminator type set to '1 ' (= EMC) indicates the support of proprietary list access commands, of 
proprietary lists and of proprietary list fields. For distinguishing proprietary elements from different 
manufacturers, the EMC is given in the following two octets. In case Discriminator type is set to '0', the 
following two octets are don't care. The PP shall not use proprietary list elements in case either the 
Discriminator type is '0' (= Undefined) or the EMC is different from the own one. 



The session identifier shall be unique between FP and one PP. It identifies the access for one list to the PP, which has 
started the session. The FP shall at least support two session at a time to one PP. 

Proprietary elements shall have identifiers with the most significant bit set to '1'. 

The submitted list entry field identifiers are used to indicate the entry field which is used by the FP to sort the requested 
list towards this PP in the given session. The FP may choose other entry fields than the ones suggested by the PP in the 
'start session' command (e.g. 'name' instead of 'first name' in contact list). The sorting capabilities of the FP depend on 
the implementation of the FP. 

For list entry field identifiers see clause 7.4.10.5.1. 

If start session is confirmed the reject reason shall not be evaluated. 

Even if the default sorting is required by the PP in the "Start session" command (using '0' as value for <Number of 
sorting fields>), the FP shall confirm the sorting fields which were actually used for sorting the list (and which shall be 
the ones defined as "default" sorting fields in clause 7.4.10.4.1.1). 

Possible error cases: 

If start session is rejected, the session identifier shall be set to 0, and the field reject reason shall indicate the appropriate 
reason. 

If a sorting field identifier is not valid, the submitted sorting field identifier shall be ignored by the FP. Nevertheless the 
FP indicates the chosen sorting field identifiers in the start session confirm. 
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Start session reject reason: 
Bits 87654321 



Meaning 



00000000 not enough resources 

00000001 list already in use by another session 
10 list not supported 

all other values reserved 

7.4.1 0.4.1 .3 "End session" command 

This command from PP or FP ends the specified session. 



Table 32: Values used within {IWU to IWU} information element 
to request the end of a list change session 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =end session> 


2H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 



This command may be sent by PP and FP to request end of session. 

The session(s) between a PP and FP shall at latest be terminated with call release. 

Remaining locked entries (see edit procedure) shall be unlocked with the end session command. 

Possible error cases: 

If session identifier is wrong the command should be ignored by the receiver. 

7.4.1 0.4.1 .4 "End session confirm" command 

This command from PP or FP confirms the ending of the specified session. 

Table 33: Values used within {IWU to IWU} information element 
to confirm the end of a list change session 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =end session 
confirm> 


3H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 



Reject of end session request shall not be possible. 

7.4. 10.4.2 Query supported entry fields 

7.4.1 0.4.2.1 "Query supported entry fields" command 

This command from PP queries the fields which are supported or not in the entries of a given list in the FP. 
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Table 34: Values used within {IWU to IWU} information element 
for the "Query supported entry fields" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command = query supported 
entry fields> 


4H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 



Possible error cases: 

If session identifier is wrong, the FP shall answer with negative acknowledgement reject reason 'invalid session 
number'. 



7.4.10.4.2.2 



"Query supported entry fields confirm" command 



This command from FP confirms the query of supported fields which are supported or not in the entries of a given list 
in the FP. 

The FP submits the supported entry field identifier and shall group them in editable and non-editable fields. 

Table 35: Values used within {IWU to IWU} information element 
for the "Query supported entry fields confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command = query supported 
entry fields confirm> 


5H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<number of editable entry fields> 


0..255 


Number of editable entry fields 


<List entry field identifier 1> 


0..255 


Supported field element type 








<List entry field identifier n> 


0..255 


Supported field element type 


<number of non-editable entry 
fields> 


0..255 


Number of non-editable entry fields 


<List entry field identifier 1> 


0..255 


Supported field element type 








<List entry field identifier n> 


0..255 


Supported field element type 


NOTE: 'Session identifier' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 



For list entry field identifiers see clause 7.4.10.5.1. 

7.4.10.4.3 Read entries 



7.4.10.4.3.1 



"Read entries" command 



This command from PP requests to read a range of consecutive entries in the list, or only a subset of the fields of these 
entries. The list here shall be understood as the list resulting from the initial sorting of the list as specified by the FP in 
the "Start session confirm" command. 

NOTE 1 : Range can be limited to one entry. 
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Table 36: Values used within {IWU to IWU} information element for "Read entries" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =read entries> 


6H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note 1) 


<Start index> 


0..127 


Start index (see note 1 ) 


<Counter> 


1..255 


Number of requested entries 


<List entry field identifier 1> 


0..255 


Requested field element type 








<List entry field identifier n> 


0..255 


Requested field element type 


NOTE 1 : 'Session identifier' and 'start index' can be extended using tlie most significant bit up to 16383. In case 
more than one byte is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded 
as 0x81 , '128' is coded as 0x01 0x80). 

NOTE 2: 'List entry field identifier' values are defined for each list separately. 



Start index: 

The start index is the first index of the range of requested entries. 



Bits 7 6 5 4 3 21 



Meaning 



0000000 
other values 

Counter (octet): 

Bits 87654321 



last entry 
list entry 



Meaning 



Oxxxxxxx forward (in ascending list index order) 

1 xxxxxxx backward (in descending list index order) 

The response contains data packets with list entries in order of ascending list index, regardless of whether counter 
indicated forward or backwards and always includes the entry with list index=start index. 

EXAMPLE: In case 2 entries are requested 'backwards' with start index 5, the data packets shall include the 
entries with indices 4 and 5, with entry 4 transmitted first. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

In case the 'start index' is invalid, the FP shall answer with negative acknowledgement, reject reason 'invalid start index'. 
This includes the case where the list is empty. 

In case the index range given with 'counter' is invalid, the FP shall return the existing elements in the range. 

In case an unknown list entry field identifier is requested, the FP shall ignore this field and continue with the next 
requested field. 



7.4.10.4.3.2 



"Read entries confirm" command 



This command from FP confirms the read command with the corresponding entry/entries with one or several specified 
fields. Corresponding entry/entries are sent along in data packets. 
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Table 37: Values used within {IWU to IWU} information element for "Read entries confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =read entries 
confirm> 


7H 


List access command 


<Start index> 


1..127 


Start index (see note) 


<Session identifier> 


1..127 


Session identifier (see note) 


<Counter> 


0..255 


Number of delivered entries 


NOTE: 'Start index' and 'Session identifier' can be extended using the most significant bit up to 16383. In case 
more than one byte is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded 
as 0x81 , '128' is coded as 0x01 0x80). 



'Counter' returns the number of returned list entries. 

'Start index' shall always indicate the smallest index value of the list response. 

Content of list entry is transmitted in data packets. 

7.4.10.4.4 Edit entry 

7.4.1 0.4.4.1 "Edit entry" command 

This command from PP requests to read and lock only one entry. 

Table 38: Values used within {IWU to IWU} information element for "Edit entry" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =edit entry> 


8H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Entry identifier> 


1..127 


Entry identifier (see note) 


<List entry field identifier 1> 


0..255 


Requested field element type 








<List entry field identifier n> 


0..255 


Requested field element type 


NOTE: 'Session identifier' and 'entry identifier' can be extended using the most significant bit up to 1 6383. In case 
more than one byte is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded 
as 0x81 , '128' is coded as 0x01 0x80). 



Whether a field element is editable or not is indicated in the response message. 

In contrast to 'read entries', the list access command 'edit entry' offers the reference to a single list entry via 'entry 
identifier'. 

FP shall prevent other PPs from changing the requested list entry (negative acknowledgement with reject reason 
'temporarily not possible') until PP has sent the save entry command or the session is terminated. 

'List entry field identifier' values are defined for each list separately. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

In case an unknown entry identifier is requested, the FP shall answer with negative acknowledgement, reject reason 
'entry not available'. 

In case an unknown list entry field identifier is requested, the FP shall ignore this field and continue with the next 
requested field. 
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7.4.10.4.4.2 



"Edit entry confirm" command 



This command from FP confirms the edit command with the corresponding entry with one or several specified fields, 
and locks this entry against access from other PPs. Corresponding entry is sent along in data packets. 

Table 39: Values used within {IWU to IWU} information element for "edit entry confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =edit entry confirm> 


9H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 



Content of list entry is transmitted in data packets. 



7.4.10.4.5 



Save entry 



7.4.10.4.5.1 



"Save entry" command 



This command from PP requests to save the entry in the list identified by the specified entry identifier, or to add a new 
entry to the list. Corresponding entry is sent along in data packets. 

The list entries which are saved shall have been requested via 'edit' before in the same session, except for creation of a 
new entry. 

The 'save' transaction shall contain all fields or a subset of the fields which were submitted in the 'edit' transaction. 

If a new entry is created, the PP shall indicate this by using the entry identifier OOH. In this case FP shall assign a new 
entry identifier for the entry, and submit it in the following 'save entry confirm'. 

Table 40: Values used within {IWU to IWU} information element for "Save entry" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command = save entry> 


AH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Entry identifier> 


0..127 


Entry identifier (see note) 


NOTE: 'Session identifier' and 'entry identifier' can be extended using the most significant bit up to 1 6383. In case 
more than one byte is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded 
as 0x81 , '128' is coded as 0x01 0x80). 



Content of list entry is transmitted in data packets. 
Entry identifier: 



Bits 7 6 5 4 3 21 



Meaning 



not yet assigned entry identifier (new entry proposed by the PP) 

other values assigned entry identifier (this entry identifier shall already exist in the list) 

If a new entry has to be created, the PP shall indicate this by using the entry identifier OOH. In this case FP shall assign a 
new entry identifier for the entry and submit it in the following 'save entry confirm'. 

The new or modified entry shall be inserted in the list by the FP taking into account the sorting criteria for this list. 

Content of list entry is transmitted in data packets. 
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If the previously started edit procedure has to be terminated without changing the list entry, PP shall perform the 'save 
entry' procedure with only one empty 'last data packet' following after 'save entry'. 

In case several fields of the same type in one entry were received during 'edit', PP shall send with 'save' all received 
fields of this type. 

Fields which shall be deleted shall be sent back to FP with length 0. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

If an unknown entry identifier of the list is requested (except 0), the FP shall answer with negative acknowledgement, 
reject reason 'entry not available'. 

If a PP attempts to save an entry with a field content which cannot be accepted, (e.g. for a field whose contents are only 
allowed once in the list like line-id in the "Line settings" list), the FP shall reject the command with a negative 
acknowledgement, with reject reason "content not accepted". 

If a PP attempts to add a new entry in a list which cannot accept an additional entry, the FP shall reject the command 
with a negative acknowledgement, with reject reason "list full". 



7.4.10.4.5.2 



"Save entry confirm" command 



This command from FP confirms the save of one entry in a list and returns the position index where the entry was 
saved. 

Table 41 : Values used within {IWU to IWU} information element for "Save entry confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command = save entry confirm> 


BH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Entry identifier> 


1..127 


Entry identifier (see note) 


<Position index> 


1..127 


Position index (see note) 


NOTE: 'Session identifier', 'position index' and 'entry identifier' can be extended using tlie most significant bit up 
to 16383. In case more than one byte is used for the value, the highbyte shall be send before the lowbyte 
(e.g. '1 ' is coded as 0x81 , '1 28' is coded as 0x01 0x80). 



The position index indicates the (possibly new) index of the entry in the list. 

Entry fields which were not indicated as editable shall not be sent back with changes within the data packet messages 
belonging to the save entry procedure. 

In case changes in non-editable fields or a change of a not previously requested (edit) entry, the FP should send negative 
acknowledge with reject reason 'procedure not allowed'. 



7.4.10.4.6 



Delete entry 



7.4.1 0.4.6.1 "Delete entry" command 

This command from PP requests to delete one entry in a list. 
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Table 42: Values used within {IWU to IWU} information element for "Delete entry" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =delete entry> 


CH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Entry identifier> 


1..127 


Entry identifier (see note) 


NOTE: 'Session identifier' and 'entry identifier' can be extended using the most significant bit up to 1 6383. In case 
more than one byte is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded 
as 0x81 , '128' is coded as 0x01 0x80). 



Delete entry is not allowed for 'List of supported lists', nor for 'DECT system settings list'. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

If an unknown entry identifier of the list is requested (except 0), the FP shall answer with negative acknowledgement, 
reject reason 'entry not available'. 

If the PP requests delete entry for 'List of supported lists' or 'DECT system settings list', the FP shall answer with 
negative achnowledgement reject reason, 'procedure not allowed'. 

7.4.1 0.6.1 .2 "Delete entry confirm" command 

This command from FP confirms the deletion of an entry in a list. 

Table 43: Values used within {IWU to IWU} information element for "Delete entry confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command = delete entry 
confirm> 


DH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Total number of available 
entries> 


0..127 


Number of available entries in list 
after deletion (see note) 


NOTE: 'Total number of available entries' and 'session identifier' can be extended using the most significant bit up 
to 16383. In case more than one byte is used for the value, the highbyte shall be send before the lowbyte 
(e.g. '1' is coded as 0x81, '128' is coded as 0x01 0x80). 



7.4.10.4.7 



Delete list 



7.4.1 0.4.7.1 "Delete list" command 

This command from PP requests the deletion of a complete list. 

Table 44: Values used within {IWU to IWU} information element for "Delete list" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =delete list> 


EH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 
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Delete list means deletion of all entries. The list itself is still available. 

Delete list is not allowed for 'List of supported lists', 'Line settings list'; nor for 'DECT system settings list'. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

If an unknown list identifier is requested (including list of supported list), the FP shall answer with negative 
acknowledgement, reject reason 'procedure not allowed'. 

In case the FP rejects the delete list command, it shall answer with negative acknowledgement, reject reason=procedure 
not allowed. 

If the PP requests delete list for 'List of supported lists'or 'DECT system settings list', the FP shall answer with negative 
achnowledgement reject reason, 'procedure not allowed'. 

7.4.1 0.4.7.2 "Delete list confirm" command 

This command from FP confirms the deletion of a complete list. 

Table 45: Values used within {IWU to IWU} information element for "Delete list confirm" command 



Information element 


Field within the Information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =delete list confirm> 


FH 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


NOTE: 'Session identifier' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 



7.4.10.4.8 



Search entries 



7.4.10.4.8.1 



"Search entries" command 



This command from PP requests to read a range of consecutive entries in the list, beginning with an entry matching a 
search criterion. The list here shall be understood as the list resulting from the initial sorting of the list as specified by 
the FP in the "Start session confirm" command. 
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Table 46: Values used within {IWU to IWU} information element for "Search entries" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command = search entries> 


10H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Matching option> 


OOH to 07H 


First part of the search criterion 


<Searched value > 




Second part of the search criterion; 
Always coded as a string 


<String length> 


1..255 




<String content 0> 




UTF-8 coded characters 








<String content n> 




UTF-8 coded characters 


<Counter> 


1..255 


Number of requested entries 


<List entry field identifier 1> 


0..255 


Requested field element type 








<List entry field identifier n> 


0..255 


Requested field element type 


NOTE: 'Session identifier' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 



In the list access command 'search entries', the submitted searched value contents together with the matching option 
define the search criterion. 

FP answers with list entries beginning with the first matching entry, but it does not generate a new list for the result. A 
matching entry shall be understood with the matching option taken into account. 

The "Search entries" command shall be considered successful if at least one entry is found that matches the search 
criterion, and even if there are less than <counter>-l entries after the matching entry in the list. See "Search entries 
confirm" command/particular cases for the case the search does not succeed (no entry found at all). 



The command 'search entries' is in principle similar to 'read entries' with the exception, that instead of 'start index' the 
'searched value' is used. 



Matching option: 
Bits 87654321 



Meaning 



00000000 exact match with whole target field required 

00000001 exact match as with OOH option tried, current start index returned if exact match fails 
00000010 exact match as with OOH option tried, previous start index returned if exact match fails 
OOOOOlxx case sensitive search required 

all other values reserved 

If 'OO'H matching option is used, the FP shall only succeed if it finds an entry in the list with first sorting field value 
equal to the searched value, and shall return an error otherwise (see possible error cases). 

NOTE 1 : This option is especially useful for the PP to retrieve a specific entry with no human intervention. 

If '01 'H matching option is used, the FP shall only succeed if either the exact match succeeds (as with option OOH), or if 
the end of the list was not reached when the exact match failed. The current entry index shall be returned as start index 
of the returned range. If the end of the list was reached when the exact match failed (there is no current entry anymore), 
the FP shall return an error (see possible error cases). 

If '02 'H matching option is used, the FP shall only succeed if either the exact match succeeds (as with option OOH), or if 
the current entry when the exact match failed was not the first entry of the list. The "previous index" = "current entry 
index -1" shall be returned as start index of the returned range. If the current entry when the exact match failed was the 
first entry of the list, the FP shall return an error (see possible error cases). 
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NOTE 2: Options '01 'H and '02'H are especially useful for searching the contact list. For example, if "Smi" is the 

searched value, with matching option 'Ol'H, and there is no entry with "Name" field equal to "Smi" in the 
list, exact match will fail on the first entry ranked after "Smi" in the list when using the alphanumerical 
order. This entry is the so-called "current entry" and may have e.g. "Smith" as "Name" field value, or any 
other value. 

Searched value: 

The FP shall use the 'searched value' as search criterion in the entry field which was used as first criterion by the FP for 
sorting the list; this sorting field is indicated to the PP in the 'Start session confirm' command. 

In case a numerical value is searched, the string content fields shall contain the lA5-coded decimal representation of the 
value (e.g. in case of searching for Line id =12, the string content is '31H 32H'). 

NOTE 3: This particular coding of numerical values does not imply anything about the underlying sorting order of 
the list, which depends on the sorting fields defined for the session and on their types (see "Start session" 
command). 

Counter (octet): 

See the "Read entries" command (clause 7.4.10.4.3), as the same definition applies here. 

Possible error cases: 

If session identifier is wrong the FP shall answer with negative acknowledgement reject reason 'invalid session number'. 

In case an unknown list entry field identifier is requested, the FP shall ignore this field and continue with the next 
requested field. 



7.4.10.4.8.2 



"Search entries confirm" command 



This command from the FP specifies the start index of the range of entries found as a result of the "Search entries" 
command, and the number of returned entries. Corresponding entry /entries are sent along in data packets. 

Table 47: Values used within {IWU to IWU} information element 
for "Search entries confirm" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command = search entries 
confirm> 


11H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Start index> 


1..127 


Start index of the range of returned 
entries (see note) 


<Counter> 


0..255 


Number of returned entries 


NOTE: 'Session identifier' and 'start index' can be extended using tlie most significant bit up to 16383. In case 
more than one byte is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded 
as 0x81 , '128' is coded as 0x01 0x80). 



Start index and counter return the index of the first returned list entry and the number of returned list entries. 

Content of list entry/entries is transmitted in data packets. 

Particular cases: 

If no entry is found that matches the search criterion, the <counter> field value shall be set to zero. No data packet shall 
be sent. 

7.4. 10.4.9 Negative Acknowledgement 

This command from FP rejects the previous command with a reject reason. 



£75/ 



107 



ETSI TS 102 527-3 VI. 1.1 (2008-06) 



Table 48: Values used within {IWU to IWU} information element for "Reject" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command=negative 
acknowledgement > 


12H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Reject reason> 


0..255 


Reject Reason 


NOTE: 'Session identifier' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 



Reject reason: 
Bits 87654321 



Meaning 



00000000 
00000001 
00000010 
0000001 1 
00000100 
00000101 
000001 10 
000001 1 1 
00001000 
00001001 



invalid range 
entry not available 
invalid session number 
temporarily not possible 
entry format incorrect 
invalid start index 
procedure not supported 
procedure not allowed 
content not accepted 
list full 



all other values reserved 

In case of 'invalid session number', the invalid session identifier of the acknowledged command is used in the negative 
acknowledgement. 

7.4. 10.4.10 Data packet / Data packet last 

These packets allow to send data content along with a command. 

Table 49: Values used within {IWU to IWU} information element for "Data packet" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Length of content> 


LH 


Length of content 


<Protocol Discriminator> 


03H 


List access 


<Command =data packet / data 
packet last> 


13H/14H 


List access command 


<Session identifier> 


1..127 


Session identifier (see note) 


<Data content byte 0> 


0.. 255 


Content first byte 








<Data content byte n > 


0.. 255 


Content last byte 


NOTE: 'Session identifier' can be extended using the most significant bit up to 16383. In case more than one byte 
is used for the value, the highbyte shall be send before the lowbyte (e.g. '1 ' is coded as 0x81 , '1 28' is 
coded as 0x01 0x80). 



'Data packet last' is used if no more data will be sent for this response. 
Data content is structured as follows: 
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Table 50: Data content structure in the "Data packet" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 


<Entry identifier for 1*" entry> 


1..127 


Identifier of the entry (see note) 


<Entry length> 


0..127 


Length (see note) 


<Entry field identifier 1 > 


0.. 255 




<Entry field length> 


0..127 


Length (see note) 


<Entry field content 0> 












<Entry field content i> 






<Entry field identifier 2 > 


0.. 255 










<Entry field identifier n > 


0..255 




<Entry field length> 


0..127 


Length (see note) 


<Entry field content 0> 












<Entry field content j> 






<Entry identifier for 2"" entry> 


1..127 


Identifier of the entry (see note) 


<Entry length> 


0..127 


Length (see note) 








Continues with further entries 






NOTE: 'Entry identifier', 'entry lengtli', and 'entry field length' can be extended using the most significant bit up to 
16383. In case more than one byte is used for the value, the highbyte shall be send before the lowbyte 
(e.g. '1 ' is coded as 0x81 , '1 28' is coded as 0x01 0x80). 



NOTE: The data content is distributed over several 'data packet' messages. One entry field might be distributed 
over more than one data packet. 

For entry field contents see clause 7.4.10.5.1. 

7.4.1 0.5 Lists and entry fields 

In the following, the entry field identifiers for various lists are defined. 

Proprietary list fields shall have entry field identifiers with the most significant bit set to '1'. 



7.4.10.5.1 
7.4.10.5.1.1 



Fields description 
Field 'List identifiers' 



Bits 



8 


7 


1 6 1 5 1 4 1 3 1 


2 


1 1 


Field identifier = List identifiers 


0/1 


Length (L) | 


0/1 


X 


1 X 1 X 1 X 1 X 1 


X 


X 


1^' supported list identifier 


2™ supported list identifier 





Octet 
1 
2 
3 
4 
5 



For octet 3 'x' indicates, the value is reserved for future use. 
The list identifiers shall be ordered in ascending numerical order. 
The list identifiers are defined in clause 7.4.10.3. 
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7.4.10.5.1.2 



Bits 



Field 'Number' 



8 


7 1 6 1 5 1 4 1 3 


2 


1 1 


Field identifier = Number 


0/1 


Length (L) | 


0/1 


editable! internal 1 own 1 x 1 x 


X 


X 


1^' digit 


2™ digit 





Octet 
1 
2 
3 

4 



Each digit shall be out of 30H. . .39H, 23H, 2AH, 05H, 15H. 

For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 



7.4.10.5.1.2.1 



Field 'number' for terminal identity numbers 



This field is also used for terminal identity numbers, if needed. In that case, the digits shall correspond to the decimal 
representation of the terminal identity numbers coded in IA5. For example: 

• For terminal 1, terminal identity number is 0000 OOOIB, coded value is 31H. 

• For terminal 14, terminal identity number is 0000 1 HOB, coded value is 3 IH 34H. 



7.4.10.5.1.3 



Bits 



Field 'Name' 



8 


7 1 


6 ! 5 ! 4 ! 3 


2 


1 1 


Field identifier = Name 


0/1 


Length (L) | 


0/1 


editable! 


X ! X ! X ! X 


X 


X 


1 ^' character byte 


2™ character byte 





Octet 
1 
2 
3 

4 



Characters shall be coded as defined for UTF-8. 

NOTE: If FP supports contact list, it is recommended to use the name from the contact list if available. 

For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 



7.4.10.5.1.4 



Bits 



Field 'Date and time' 



8 


7 ! 6 ! 5 ! 4 ! 3 ! 


2 ! 


1 1 


Field identifier = Date and time 


0/1 


Length (L) | 


0/1 


editable x x x ! x 


X ! 


X 




Content as specified for IE «Time-DATE» 


octet 3 






Content as specified for IE «Time-DATE» 


octet 4 







Octet 
1 
2 
3 
4 
5 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

Octets 4 and following are coded as specified for octets 3 and following in IE «Time-Date» (EN 300 175-5 [5]). 
Only 'interpretation' 000000 (=current time/date) is allowed. Any 'coding' is allowed (time or date or time&date). 

In case of multiple calls it is recommended that date and time indicate the last call. 
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7.4.10.5.1.5 



Bits 



Field 'New' 



8 


7 1 


6 1 5 1 4 1 3 


2 


1 1 


Field identifier = New 


0/1 


Length (L) | 


0/1 


editable! 


new 1 X 1 X 1 X 


X 


X 



Octet 
1 
2 
3 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

When a new entry is created, the bit 'new' shall be set by the FP. The FP shall reset the bit upon reading of the entry 
from any PP. 



7.4.10.5.1.6 Field 'Line name' 

Bits 



8 


7 1 


6 ! 5 ! 4 ! 3 


2 


1 1 


Field identifier = Line name 


0/1 


Length (L) | 


0/1 


editable! 


X ! X ! X ! X 


X 


X 


1 ^' character byte 


2™ character byte 





Octet 
1 
2 
3 
4 
5 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

Characters shall be coded as defined for UTF-8. 



7.4.10.5.1.7 


Field 'Line id' 








Bits 


8 ! 7 ! 


6 ! 5 ! 4 ! 3 


2 ! 1 


Octet 




Field identifier = Line id 


1 




0/1 


Length (L) 


2 




0/1 


editable! 


X ! X ! X ! X 


X ! X 


3 




Identifier subtype 






0/1 


Identifier value 














0/1 


Identifier value 





For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

The structure of the Line id field aligns to the structure of IE «CALL-INFORMATION» line identifier type (see 
EN 300 175-5 [5], clause 7.7.56). 

For all call-related lists, if the entry where the field is included corresponds to an internal call, the line id field shall be 
present but empty (length set to '0'). 

Identifier subtype values: 

• For all call-related lists, the subtype shall be set to "Line identifier for external call" (call is external). 

• For the "Contact list", subtype shall be set to "Relating to" or "All lines", depending on the contact. 

• For the "Line settings" list, and for any other list, the subtype shall be set to "Relating to". 
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7.4.10.5.1.8 



Bits 



Field 'Number of calls' 



8 


7 1 


6 1 5 1 4 1 3 1 


2 


1 1 


Field identifier = Number of calls 


0/1 


Length (L) | 


0/1 


editable! 


X 1 X 1 X 1 X 1 


X 


X 


value 



Octet 
1 
2 
3 

4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 



7.4.10.5.1.9 


Field 'Call type' 














Bits 


8 1 7 1 6 1 5 1 4 1 3 


2 


1 


Octet 




Field identifier = Call type 


1 




0/1 


Length (L) 


2 




0/1 


editable 


Missed 
call 


Accepted 
call 


Outgoing 
call 


X 


X 


X 


3 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 



7.4.10.5.1.10 



Bits 



Field 'First name' 



8 


7 1 


6 1 5 1 4 1 3 


2 


1 1 


Field identifier = First name 


0/1 


Length (L) | 


0/1 


editable 1 


X 1 X 1 X 1 X 


X 


X 


1 ^' character byte 


2"'' character byte 





Octet 
1 
2 
3 

4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

Characters shall be coded as defined for UTF-8. 



7.4.10.5.1.11 



Bits 



Field 'Contact number' 



8 


7 1 6 1 5 1 4 1 3 1 


2 1 


1 1 


Field identifier = Contact number 


0/1 


Length (L) | 


0/1 


editable! default 1 own 1 Fixed 1 mobile 1 


work 1 


X 


1^' digit 


2™ digit 





Octet 
1 
2 
3 

4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

Field 'contact number' can be contained several times in one entry. 

A digit is out of 30H...39H, 23H, 2AH, 05H, 15H. 
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Bits 



112 



Field 'Associated melody' 



8 


7 1 6 1 5 1 4 1 3 1 


2 


1 1 


Field identifier = Associated melody 


0/1 


Length (L) | 


0/1 


editable! X 1 X 1 X 1 X 1 


X 


X 1 


Value 1 
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Octet 
1 
2 
3 

4 



For octet 3, each bit indicates whether a property of the field is given (1) or not (0). In case of 'x', the value is reserved 
for future use. 

7.4.10.5.2 "List of supported lists" entry fields 

This list contains the identifiers of the lists which are supported by the FP (as some lists are optional on FP side) 

Table 51 : "List of supported lists" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


0x01 


List identifiers 


Single variable-length field with 
identifiers of all supported lists 


7.4.10.5.1.1 



The list identifiers are defined in clause 7.4.10.3. 

The 'List of supported lists' refers to a list with only one entry. 

NOTE: The list identifiers are ordered in ascending numerical order (see clause 7.4.10.5.1.1). 

7.4.10.5.3 "Missed call list" entry fields 

This list contains all the missed calls occurring on any line of the DECT system. 

Table 52: "Missed call list" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


0x01 


Number 


Number of the calling party 


7.4.10.5.1.2 (see note) 


0x02 


Name 


Name of the calling party 


7.4.10.5.1.3 


0x03 


Date and Time 


Date and Time of the missed call 


7.4.10.5.1.4 


0x04 


New 


Indicates whether entry is shown first 
time 


7.4.10.5.1.5 


0x05 


Line name 


Name of line on which the call was 
received 


7.4.10.5.1.6 


0x06 


Line id 


Id of line on which the call was 
received 


7.4.10.5.1.7 


0x07 


Number of calls 


Indicates amount of missed calls 
from this calling party 


7.4.10.5.1.8 


NOTE: The "IVIissed call list" may include internal calls (e.g. if allowed by configuration). 
Clause 7.4.10.5.1.2.1 describes the coding of terminal identity numbers. 
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7.4. 10.5.4 "Outgoing call list" entry fields 

This list contains all outgoing calls occurring on any line of the DECT system. 

Table 53: "Outgoing call list" entry fields 



ETSI TS 102 527-3 VI. 1.1 (2008-06) 



Field identifier 


Field 


Normative action/comment 


Clause 


0x01 


Number 


Number of the called party 


7.4.10.5.1.2 (see note) 


0x02 


Name 


Name of called party 


7.4.10.5.1.3 


0x03 


Date and Time 


Date and Time of the call 


7.4.10.5.1.4 


0x04 


Line name 


Indicates name of line used for the call 


7.4.10.5.1.6 


0x05 


Line id 


Id of line line used for the call 


7.4.10.5.1.7 


NOTE: The "Outgoing call list" may include internal calls (e.g. if allowed by configuration). 
Clause 7.4.10.5.1.2.1 describes the coding of terminal identity numbers. 



7.4.1 0.5.5 "Incoming accepted call list" entry fields 

This list contains all the accepted incoming calls occurring on any line of the DECT system. 



Table 54: "Incoming accepted call list" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


0x01 


Number 


Number of the calling party 


7.4.10.5.1.2 (see note) 


0x02 


Name 


Name of calling party 


7.4.10.5.1.3 


0x03 


Date and Time 


Date and Time of the call 


7.4.10.5.1.4 


0x04 


Line name 


Name of line on which the call was 
received 


7.4.10.5.1.6 


0x05 


Line id 


Id of line line used for the call 


7.4.10.5.1.7 


NOTE: The "Incoming accepted call list" may include internal calls (e.g. if allowed by 

configuration). Clause 7.4.10.5.1.2.1 describes the coding of terminal identity numbers. 



7.4.10.5.6 "All call list" entry fields 

This list contains all calls (missed, outgoing, incoming accepted) occurring on any line of the DECT system. 

Table 55: "All call list" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


0x01 


Call type 


Coding of the list: 

missed / accepted / outgoing 


7.4.10.5.1.9 


0x02 


Number 


Number of the calling/called party 


7.4.10.5.1.2 (see note) 


0x03 


Name 


Name of calling/called party 


7.4.10.5.1.3 


0x04 


Date and Time 


Date and Time of the missed call 


7.4.10.5.1.4 


0x05 


Line name 


Name of line on which the call was 
received/passed 


7.4.10.5.1.6 


0x06 


Line id 


Id of line line used for the call 


7.4.10.5.1.7 


NOTE: The "All call list" may include internal calls (e.g. if allowed by configuration). 
Clause 7.4.10.5.1.2.1 describes the coding of terminal identity numbers. 
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7.4.10.5.7 "Contact list" entry fields 

This list contains the contact hst (or phone book) for the complete DECT system. 

Table 56: "Contact list" entry fields 
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Field identifier 


Field 


Normative action/comment 


Clause 


0x01 


Name 


Name of tlie contact (last name) 


7.4.10.5.1.3 


0x02 


First name 


First name of the contact 


7.4.10.5.1.10 


0x03 


Contact number 


Number of the contact 


7.4.10.5.1.11 


0x04 


Associated melody 


Ringing melody used for the contact 


7.4.10.5.1.12 


0x05 


Line id 


Id of line used for the call 


7.4.10.5.1.7 



If the entry is related to all lines in the system, the field 'Line id/subtype' shall be set to "All lines". 
7.4.1 0.5.8 "Internal names list" entry fields 

This list contains the names of registered PPs of the complete DECT system. 

Table 57: "Internal names list" entry fields 



Field identifier 


Field 


Normative action/comment 


Clause 


0x01 


Number 


Terminal identity number 


7.4.10.5.1.2 (see note) 


0x02 


Name 


Name of the internal party 


7.4.10.5.1.3 


NOTE: Clause 7.4.10.5.1.2.1 speficies the coding of terminal identity numbers. 



One and only one entry per terminal identity number shall exist in the "Internal names" list. If a PP attempts to save an 
entry with an already existing "Number" field, the FP shall reject it with negative acknowledgement with reject reason 
"content not accepted". 

When a PP registers to the FP, the FP shall automatically add a corresponding entry in the internal names list (see 
clause 7.4.10.5.10). 

7.4.10.5.9 "DECT system settings list" entry fields 

See clause 7.4. 11.3. 

7.4.10.5.10 "Line settings list" entry fields 

See clause 7.4. 11.4. 

7.4.10.6 Generic sequence charts for list access 

See clause C.1.1 for examples of sequence charts for list access. 

7.4.10.7 Use case examples for list access 

See clause C. 1 .2 for examples of use cases for list access. 

7.4.1 1 DECT system and line settings 



7.4.11.1 



DECT system and line settings considerations 



DECT system and line settings shall use the "List access service" procedures with the following additional 
requirements. 

DECT system settings consist of a set of settings that are valid for the complete DECT system, i.e. valid for all 
registered PPs independently of line / multiple line concepts. They are stored in the FP as a unique list with only one 
entry in the list. Each setting is a field of this entry. 
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Line settings consist of a set of settings that are valid for one line of the DECT system, i.e. valid for all registered PPs 
attached to this line. They are stored in the FP as a unique list with one entry per line in the list. Each setting is a field of 
this entry. Even if the DECT system does not implement multiple line features, the FP and PP shall support line settings 
with only one entry: the settings for the only line supported by the system. 

Sorting of the lists: 

No sorting is defined for the "DECT system settings" list, as it contains only one entry. 

The "Line settings" list is sorted by ascending line id number. 

Commands: 

All the "List access service" feature commands shall be supported for the "DECT system and line settings" feature, 
except for: 

• The "delete entry" command is not allowed for the "DECT system settings" list. 

The "delete list" command is not allowed for the "DECT system settings" list, nor for the "Line settings" list. 

These commands shall not be invoked by any PP and shall be answered with negative acknowledgement from the FP 
with reject reason "procedure not allowed" (see clause 7.4.10.4.9). 

Saving a new line setting entry or deleting a line setting entry is allowed (when creating or removing a line for the 
DECT system). Please refer to clause 7.4. 1 1 .2 "Interactions between registration, attachment of handsets and lists" for 
impacts. 

Only one entry per line identifier shall exist in the "Line settings" list. In other words, two distinct entries shall never 
have the same line id (see clause 7.4. 11. 3 for details). 

Settings: 

Some DECT system or line settings are mandatory and shall be supported both by the FP and the PP. Please refer to 
table 1 for status of each setting. When a setting is mandatory in the table, all related fields are mandatory. 

The PP may use the "Query supported entry fields" procedure (see clause 7.4.10.4.2) to know which settings are 
supported by the FP. The FP shall answer with mandatory and optional settings implemented in the FP. This way, the 
PP will be able to give proper indication to the user (when accessing to the settings menus for example). 

All settings shall have default value set when product is manufactured. All these settings may be reset to default value 
with the "Base reset" setting. 

For variable-length settings, if the value is not defined by the user, the length of the field shall be set to zero. 

EXAMPLE: If no dialling prefix is set, length of this field shall be zero. 

The PP may modify 1 to n setting(s) by using an "Edit entry" command with following parameters: (session identifier, 
entry identifier=l, 1 to n field identifiers). 

PIN code: 

For security reasons, the PIN code shall never be sent over the air on a non ciphered link. Moreover, the FP shall 
prevent a non-allowed PP to save a new PIN code: 

At least when accessing the 'PIN code' setting of the "DECT system settings" list, with any command, the connection 
shall be ciphered and conditioned to correct PIN keyboarding; i.e. for "Read entries confirm", "Search entries confirm" , 
"Edit entry confirm", "Save entry" and "Save entry confirm" commands that includes the PIN code field in data packets: 

• The DECT link shall be ciphered prior to the command. If this not the case, the FP shall answer with a 
negative acknowledgement, reject reason = "procedure not allowed" (see clause 7.4.10.4.9). 

• Before saving a new PIN code, the PP shall perform "Edit entry" on the PIN code, and check that the return 
value matches the PIN code just entered by user. 

• Only after edit, the PP may save the new PIN code value. 



£75/ 



116 



ETSI TS 102 527-3 VI. 1.1 (2008-06) 



Access to the "DECT system settings" menu on the PP may be conditioned to prior PIN code keyboarding and may be 
completely in ciphered mode. This is left free to the implementer. 

Initial value: 

The "DECT system settings" list unique entry is at position index 1 in the DECT system list. 
First "Line settings" list entry is at position index 1 in the line settings list. 



7.4.11.2 



Interactions between registration, attachments of handsets and lists 



"Internal names" list fully reflects the registered PPs. At registration of a handset, the FP shall add a new entry in the 
"Internal names" list with a default name. (For example "DECT n" where n stands for the terminal identity number in 
decimal representation). "Attached handsets" setting in the corresponding line setting(s) shall also automatically be 
updated by the FP with corresponding bit. Attachment may be initiated by the PP or done on FP side (default 
attachment or e.g. through a web to FP interface). 

Except during temporary period (modifications/creations/delete of lines), a registered handset shall always be attached 
to at least one line: the PP shall appear at least in one "attached handset" field of one line setting. It may appear in 
several line settings if it is attached to several lines. Deleting an entry in the "Internal names" list shall result in de- 
registration of the corresponding handset. "Attached handsets" field in the line setting(s) list shall also be automatically 
updated by the FP. Deleting one entry (one line) of the line settings list shall result in the de-attachment of the 
corresponding handsets from the line. 

If, as a consequence of a "delete entry" command on the line settings list, a handset is no longer attached to any line 
anymore, it shall however remain registered and available in the "Internal names" list. This handset is no longer 
reachable from external lines. This temporary state may arise especially when removing and creating new lines. 

NOTE 1 : This mechanism makes it possible to register/unregister any handset to/from the DECT system, and to 
attach/detach it to/from a line in two separate steps. 

NOTE 2: As specified in the "Multiple lines" feature NG1.N.14, attachment may be PP-managed (for example, the 
user chooses the line at registration) or FP-managed (for example, the handset is attached by default to a 
line). 

If the "Base reset" influences the "Internal names" list or the "Line settings" list attached handsets, the corresponding 
handsets de-attachments and un-registrations shall be correctly handled. 

7.4.1 1 .3 DECT system settings list 

The following entry fields are defined for the (singular) DECT system list entry. 

Table 58: Entry fields for the (singular) DECT system list entry 



Field 
identifier 


Field 


Default 
value 


Base 

reset 

impacted 


Normative action/comment 


Clause 


0x01 


PIN code 


YES/MD 


MD 


Allows modification of the PIN code 


7.4.11.3.1 


0x02 


Clock master 


MD 


MD 


Defines the entity which sets date an 
time for the DECT system (PP or FP) 


7.4.11.3.2 


0x03 


Base reset 


YES 


YES 


Sets settings back to default factory 
values 


7.4.11.3.3 


0x04 


FP IP address / type 


MD 


MD 


DHCP or static 


7.4.11.3.4 


0x05 


FP IP address / value 


MD 


MD 


Editable only for static IP address 


7.4.11.3.5 


0x06 


FP IP address / subnet mask 


MD 


MD 


Editable only for static IP address 


7.4.11.3.6 


0x07 


FP IP address / gateway 


MD 


MD 


Only for static IP address 


7.4.11.3.7 


0x08 


FP IP address / DNS server 


MD 


MD 


Only for static IP address 


7.4.11.3.8 


0x09 


FP version / Firmware version 


YES/MD 


NO 


Software version of the FP 


7.4.11.3.9 


OxOA 
OxOB 


FP version / Eeprom version 
FP version / Hardware version 


YES/MD 
YES/MD 


NO 
NO 


Eeprom version of the FP 
Hardware version of the FP 


7.4.11.3.10 
7.4.11.3.11 
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Default value: it is the value of the setting when product is manufactured: 

• "YES" means that a default value is standardized. See corresponding setting clause definition. 

• "MD" means that a default value shall be provided by the manufacturer (could also be empty or a zero length 
setting). 

• "YES/MD" means that a default value shall be provided by the manufacturer, which shall not be empty. 
"Base reset" impacted: describes the impact of the "Base reset" setting on this particular setting: 

• "YES" means setting is reset to default value when "Base reset" setting is activated. 

• "NO" means setting is not impacted by "Base reset" setting. 

• "MD" means manufacturer defines if the setting is impacted or not by the "Base reset" setting. 

7.4.11.3.1 Field 'PIN code' 

The 'PIN code' field shall be coded as follows. 

Bits 8 I 7 I 6 ~\ 5 \ 4 \ 3 \ 2 \ 1 | Octet 

1 
2 
3 
4 



8 


7 1 


6 1 5 1 4 1 3 


2 


1 


Field identifier = PIN code 


0/1 


Length (L) 


0/1 


Editable! 


X X X X 


X 


X 


1^' digit 


2™ digit 




8'" digit 



Each digit shall be out of 2 AH and interval 30H..39H. 
The 'PIN code' field shall respect the following rules: 

• Each decimal digit entered by the user, is translated into one octet (ASCII coded). The PT shall be capable to 
accept any PIN between and 8 decimal digits (limits included). 

• The PIN shall always have a length of 8 digits, the resulting string of octets is padded with a number of leading 
"*" octets to achieve a total of 8 octets (for example if the PIN code is only 4 digits). For example, a value of 
"1091" (4 decimal digits entered via keypad) is translated into a pin code of the following value: "****! 091", 
and coded as shown in figure 40. 

I 2AH I 2AH I 2AH I 2AH I 31 H I 30H I 39H I 31 H I 



Figure 40: Example of PIN code coding 



7.4.11.3.2 Field 'Clock master' 

The 'Clock master' field shall be coded as follows 
Bits 



8 


7 1 


6 1 5 1 4 1 3 


2 


1 


Field identifier = clock master 


0/1 


Length (L) 


0/1 


Editablel 


X X X X 


X 


X 


Value 



Octet 
1 
2 
3 

4 



Value shall be 30H or 31H. 30H stands for FP, 31H stands for PP. 

The behaviour of the PP and FP according to 'Clock master' field setting shall be consistent with the "Date and Time 
synchronization" feature described in clause 7.4.2. 
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7.4.11.3.3 Field 'Base reset' 

The 'Base reset' field shall be coded as follows. 
Bits 



8 


7 1 


6 1 5 1 4 1 3 


2 


1 


Field identifier = base reset 


0/1 


Length (L) 


0/1 


Editable! 


X X X X 


X 


X 


Value 



Octet 
1 
2 
3 

4 



Value shall be 30Hor 31H. 30H stands for 'No', 31H stands for 'Yes'. 
The 'Base reset' field shall respect the following rules: 

• If at least one DECT system setting, or line setting, has been set to a non default value, the 'Base reset' field 
shall be equal to 'No' when a PP performs a read command. 

• If a registered PP sets the value to 'Yes', all DECT system and line settings shall be reset to their default value. 
The setting remains set to 'Yes' until any DECT system or line setting is changed. 

• Any attempt from a PP to set this parameter to 'No' shall result in a negative acknowledgement, with reject 
reason "procedure not allowed" from the FP (see clause 7.4.10.4.9). 

Default value: 3 IH ('Yes'). 

7.4.1 1 .3.4 Field 'FP IP address / type' 

The 'IP address type' field shall be coded as follows. 

Bits 8 I 7 I 6 I 5 \ 4 \ 3 \ 2 \ 1 | Octet 

1 
2 
3 



8 1 7 


6 1 5 1 4 1 3 1 


2 


1 


Field identifier = IP address type 


0/1 


Length (L) 


Editable 


DHCP 


Static 1 X 1 X 1 X 1 


X 


X 



The IP address of the FP may be assigned dynamically using DHCP or manually using a static address entered by the 
user. 

The length of the field shall be set to zero when the value of the field is not defined by the user. 

7.4.1 1 .3.5 Field 'FP IP address / value' 

The 'IP address value' field shall be coded as follows. 

Bits 8 I 7 I 6 I 5 \ 4 \ 3 \ 2 \ 1 | Octet 

1 
2 
3 
4 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 


Field identifier = FP IP address / value 


0/1 


Length (L) 


0/1 


Editablel IPv4/6 | X | x | x | X 


X 


l^'byte 


2™ byte 


3™ byte 





IPv4/6: if set to 0, the format is IPv4 (4 bytes long); if set to 1, the format is IPv6 (16 bytes long). 

An IPv4 address shall always have a length of 4 bytes. 

EXAMPLE 1: A value of 192.168.213.1 is translated into an 'IP address / value' field with the following bytes: 
'C0A8D501'H. 

An IPv6 address shall always have a length of 16 bytes. 
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EXAMPLE 2: A value of fdl 1 :2233:4455: 1 :a:b:c:d is translated into an IP address / value' field with the 
following bytes: 'FD11223344550001000A000B000C000D'H. 

The length of the field shall be set to zero when the value of the field is not defined by the user. 

7.4.1 1 .3.6 Field 'FP IP address / subnet mask' 

The 'IP address value' field shall be coded as follows. 

Bits I 8 \ 7 \ 6 \ 5 \ 4 \ 3 \ 2 \ 1 | Octet 

1 
2 
3 
4 



8 


7 1 6 1 


5 1 4 1 3 1 2 


1 




Field identifier = 


= FP IP address / subnet mask 




0/1 


Lengtii (L) 


0/1 


Editable! IPv4/6 1 


X 1 X 1 X 1 X 


X 


l^'byte 


2™ byte 


3™ byte 





IPv4/6: if set to 0, the format is IPv4 (4 bytes long), if set to 1, the format is IPv6 (16 bytes long). 

A subnet mask for IPv4 shall always have a length of 4 bytes. 

EXAMPLE 1: A value of 255.255.255.0 is translated into an 'IP address / subnet mask' field with the following 
bytes: 'FFFFFFO'H. 

A subnet mask for IPv6 shall always have a length of 16 bytes. 

EXAMPLE 2: A subnet mask corresponding to a 59-bit prefix is translated into an 'IP address / subnet mask' field 
with the following bytes: 'FFFF FFFF FFFF FFEO 0000 0000 0000 OOOO'H. 

The length of the field shall be set to zero when the value of the field is not specified by the user. 
7.4.1 1 .3.7 Field 'FP IP address / gateway' 

The 'FP IP address / gateway' field shall be coded as follows. 



Bits 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 


Field identifier = FP IP address / gateway' 


0/1 


Length (L) 


0/1 


Editable! IPv4/6 1 X 1 x 1 x 1 X 


X 


l^'byte 


2™ byte 


3™ byte 





Octet 
1 
2 
3 

4 



IPv4/6: if set to 0, the format is IPv4 (4 bytes long), if set to 1, the format is IPv6 (16 bytes long). 

The 'FP IP address / gateway' field shall always have a length of 4 bytes (IPv4) or 16 bytes (IPv6). See the 'IP address / 
value' field for more information. 

The length of the field shall be set to zero when the value of the field is not specified by the user. 
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7.4.1 1 .3.8 Field 'FP IP address / DNS server' 

The 'DNS server' field shall be coded as follows. 
Bits 



8 


7 1 6 1 


5 1 4 1 3 1 2 


1 




Field identifier -- 


= FP IP address/ DNS server 




0/1 


Lengtii (L) 


0/1 


Editable! IPV4/6 1 


X 1 X 1 X 1 X 


X 


l^'byte 


2™ byte 


3™ byte 





Octet 
1 
2 
3 

4 



IPv4/6: if set to 0, the format is IPv4 (4 bytes long), if set to 1, the format is IPv6 (16 bytes long). 

The 'FP IP address / DNS server' field shall always have a length of 4 bytes (IPv4) or 16 bytes (IPv6). See the 'IP 
address / value' field for more information. 

The length of the field shall be set to zero when the value of the field is not specified by the user. 

The 'FP IP address / DNS server' field may be included several times in the entry: main server and alternate server. 

7.4.1 1 .3.9 Field 'FP version / Firmware version' 

The 'firmware version' field shall be coded as follows. 



Bits 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 


Field identifier = FP version / Firmware version 


0/1 


Length (L) 


0/1 


X X X X X X 


X 


1 ^' character byte 


2™ character byte 





Octet 
1 
2 
3 
4 
5 



Characters shall be coded as defined for UTF-8. 

7.4.1 1 .3.1 Field 'FP version / Eeprom version' 

The 'Eeprom version' field shall be coded as follows. 
Bits 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 


Field identifier = FP version / Eeprom version 


0/1 


Length (L) 


0/1 


X 1 X 1 X 1 X 1 X 1 X 


X 


1 ^' character byte 


2™ character byte 





Octet 
1 
2 
3 
4 
5 



7.4.1 1 .3.1 1 Field 'FP version / Hardware version' field 

The 'Hardware version' field shall be coded as follows. 
Bits 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 


Field identifier = FP version / Hardware version 


0/1 


Length (L) 


0/1 


X 1 X 1 X 1 X 1 X 1 X 


X 


1 ^' character byte 


2™ character byte 





Octet 
1 
2 
3 
4 
5 



Characters shall be coded as defined for UTF-8. 
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Table 59: Entry fields for a line settings list entry 



Field 
identifier 


Field 


Default valueBase 
reset impacted 


Normative action/comment 


Clause 


0x01 


Line name 


MD 


MD 


Name of the line 


7.4.11.4.1 


0x02 


Line id 


MD 


NO 


Line identifier 


7.4.11.4.2 


0x03 


Attached handsets 


MD 


MD 


List of registered handsets which are 
attached to the line. 


7.4.11.4.3 


0x04 


Dialling prefix 


MD 


MD 


If defined, adds a prefix to called party 
numbers for calls placed on the line. 


7.4.11.4.4 


0x05 


FP melody 


YES/MD 


MD 


Melody of the FP linked to this line. 


7.4.11.4.5 


0x06 


FP volume 


YES/MD 


MD 


Melody volume of the FP linked to this line. 


7.4.11.4.6 


0x07 


Blocked telephone 
number 


MD 


MD 


Forbidden called party numbers on the line 


7.4.11.4.7 


0x08 


IVIultiple calls mode 
(single/multiple) 


MD 


MD 


Current mode of the line: single call or 
multiple call 


7.4.11.4.8 


0x09 


Intrusion call 


MD 


MD 


Intrusion call YES / NO 


7.4.11.4.9 


OxOA 


Permanent CLIR 


YES 


MD 


Restrict number for all outgoing calls on 
this line 


7.4.11.4.10 


0x0 B 


Call forwarding 


YES 


MD 


Stores the type and number of the call 
forwading. 


7.4.11.4.11 



Default value: it is the value of the setting when product is manufactured. 

• "MD" means that a default value, if any, shall be provided by the manufacturer (could also be empty or zero 
length setting). 

• "YES/MD" means that a default value shall be provided by the manufacturer (shall not be empty). 

• "YES" means that a default value is standardized. See corresponding setting clause definition. 
Base reset impacted: describes the impact of the "Base reset" setting on the given setting. 

• "YES" means that the setting is reset to default value when "Base reset" setting is activated. 

• "NO" means that thesetting is not impacted by "Base reset" setting. 

• "MD" means "manufacturer defined", whether or not the setting is impacted by the "Base reset" setting. 

The list shall be sorted by ascending numerical order of the 'Line id' field values. 

Only one entry per line identifier shall exist in the line settings list. In other words, two distinct entries shall never have 
the same line id. If a PP attempts to add or modify an entry with an already existing line id in one entry of the list, the 
FP shall reject it with negative acknowledgement (clause 7.4.10.4.9) / reject reason = 'content not accepted'. 

When the line name of a specific line is modified, the FP should automatically update the other lists where line name is 
stored (especially call lists). 

7.4.11.4.1 Field 'Line name' 

See 'Line name' field in "List access service" feature, clause 7.4.10.5.1.6. 

7.4.11.4.2 Field 'Line id' 

See 'Line id' field in "List access service" feature, clause 7.4.10.5.1.7. 
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7.4.11 .4.3 Field 'Attached handsets' 

The 'Attached handsets' field shall be coded as follows 
Bits 



8 


7|6|5|4|3|2|1 





Field identifier = Attached handsets 


Length (L) 


0/1 


Editable! x | X | x | x | X | X 


0/1 


Number of registered handsets attached to the line 


0/1 


Handset bitmap 


0/1 




0/1 


Handset bitmap (continued) 



Octet 
1 
2 
3 
4 
5 

5n 



Number of registered handsets attached to the line (octet 4): 

The number of handsets relates to the number of handsets attached to the line. The value shall be coded with the natural 
binary value, with the least significant bit in bit position "1". Allowable values are "1" to "255". 

Handset bitmap (octet group 5): 

This is a bitmap octet group, with the handset number 1 in bit position "1". A "1" indicates handset is attached to the 
line, and a "0" indicates it is not. 



Handset bitmap (octet 5n): 
Bits 7 6 5 4 3 21 

X X X X X X 1 

X X X X X 1 X 

X X X X 1 X X 

X X X 1 X X X 

X X 1 X X X X 

X 1 X X X X X 

1 X X X X X X 



Meaning 

Handset number 1 is attached 
Handset number 2 is attached 
Handset number 3 is attached 
Handset number 4 is attached 
Handset number 5 is attached 
Handset number 6 is attached 
Handset number 7 is attached 



NOTE 1 : If the extension bit is "0" in the first octet (indicating presence of an additional octet), the least significant 
bit of second octet stands for handset number 8. 

NOTE 2: The format of the current field is a bit mask, it is different from the format of the number field of the 
internal names list (terminal id number) but represents the same handset numbers. 

7.4.11.4.4 Field 'Dialling Prefix' 

See'Number' field in "List access service" feature, clause 7.4.10.5.1.2. 

The prefix shall be added by the FP to the called party number to any external outgoing call placed on the line. 

The length of the field shall be set to zero when the value of the field is not defined. 

7.4.11.4.5 Field 'FP melody' 

See 'Associated melody' field in "List access service" feature, clause 7.4.10.5.1.12. 

This field defines the melody to be used to ring in the FP on an incoming call on a dedicated line. 

7.4.11.4.6 Field 'FP volume' 

The 'FP volume' field shall be coded as follows. 

Bits I 8 \ 7 \ 6 \ 5 \ 4 \ 3 \ 2 \ 1 | Octet 

1 
2 
3 
4 



8 


7 1 


6 1 5 1 4 1 3 


2 


1 


Field identifier = volume 


0/1 


Length (L) 


0/1 


editable 


X X X X 


X 


X 


Value 
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Value shall be out of interval 30H..39H. 



7.4.11.4.7 



Field 'Blocked number' 



See 'Number' field in "List access service" feature, clause 7.4.10.5.1.2, except that the possible value shall be out of 
interval 30H..39H, and 2AH value. 

The 'blocked number' field may be composed of: 

• either a single phone number value, 

• or a range of phone number values. In this case, the 'Number' field shall be equal to a sequence of one or more 
digit(s) followed by '*'. For example: "02*" represents all numbers starting with "02" digit sequence. 

When a PP attached to the line tries to place an external outgoing call on a number which is blocked, this call shall not 
be established by the FP. The FP shall release the call. 

This field may be contained several times in line settings entry. This allows to block several numbers or ranges of 
numbers. The number of times the field is included shall be defined at line setting entry creation. See clause 7.4.10.4.5 
list access 'Save entry' command procedure for details how to handle several fields of the same type in the same entry. 

The length of the field shall be set to zero when the value of the field is not defined. 



7.4.1 1 .4.8 Field 'Multiple calls mode' can be contained several times in one entry 

The 'Multiple calls mode' field shall be coded as follows. 



Bits 



8 


7 1 6 1 5 1 4 1 3 1 


2 


1 


Field identifier = IVIultiple calls mode 


0/1 


Length (L) 


0/1 


Editable x X x x 


X 


X 


Value 



Octet 
1 
2 
3 

4 



Value shall be 30H or 31H. 30H stands for "Single call mode", 31H for "Multiple call mode". 

This field is related to the "Multiple calls" feature (see clause 7.4.8) and allows to configure a multiple call line in single 
call mode. For non-multiple call lines, the value "Single call mode" shall always be used. 



7.4.11.4.9 Field 'Intrusion call' 

The 'intrusion call' field shall be coded as follows: 
Bits 



8 


7 1 6 1 5 1 4 1 3 1 


2 


1 


Field identifier = Multiple calls mode 


0/1 


Length (L) 


0/1 


Editable x X x x 


X 


X 


Value 



Octet 
1 
2 
3 

4 



Value shall be 30H or 31H. 30H stands for intrusion call not allowed, 31H for intrusion call allowed. 

This field is related to the "intrusion call" feature (see clause 7.4.3.8). For "Implicit call intrusion" (see clause 7.4.3.8.1), 
the value also indicates the behavior of the system when a call setup is attempted on the line (real call setup, vs call 
intrusion). 
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7.4.11.4.10 Field 'Permanent CLIP' 

The 'Permanent CLIR' field shall be coded as follows. 
Bits 



8 


7 1 6 1 5 1 4 1 3 1 


2 


1 


Field identifier ^Permanent CLIR 


0/1 


Length (L) 


0/1 


Editable x X x x 


X 


X 


Value 


CLIR code 1" digit 


CLIR code 2"" digit 



Octet 
1 
2 
3 
4 
5 



Value shall be 30H or 31H. 30H stands for CLIR de-activated for all calls, 31H for CLIR activated for all calls. 

Each digit shall be out of interval 30H..39H, and values 23H, 2AH, 05H and 15H. 

If a PP sets or resets the value, the FP shall activate or deactivate the CLIR service in the network using the CLIR code 
for all outgoing calls placed on the specified line. This setting shall be consistent with the CLIR feature (NGLN.17). 

If the CLIR code is not relevant (depending on the Network type), the FP may set the length of the field so that the field 
only includes the value octet. 

Default value: 30H: 'de-activated'. Default CLIR code is "manufacturer defined". 



7.4.11.4.11 Field 'Call forwarding' 

The 'Call forwarding' field shall be coded as follows. 
Bits 



8 


7 1 


6 1 5 1 4 1 3 1 


2 


1 


Field identifier =Call forwarding 


0/1 


Length (L) 


0/1 


Editablel 


X X X X 


X 


X 


CF type 


1^' digit 


2™ digit 



Octet 
1 
2 
3 

4 



CF type shall be 30H, 31H or 32H. 30H stands for CFU (Call forwarding unconditional), 31H for CFB (Call forwarding 
busy), and 32H for CFNR (Call forwarding on non response). 

The digits represent the call forwarding target number. 

The length of the field shall be set to zero when the value of the field is not defined by the user. 

If a PP sets or resets the field, the FP shall activate or deactivate the corresponding Call forwarding in the network for 
specified type of calls received and on the specified line. 

This field may be contained several times in the line settings entry. This allows to define several call forwarding types 
for the line. The number of times the field is included shall be defined at line setting entry creation. See 
clauses 7.4.10.4.5 list access 'Save entry' command procedure for details on how to handle several identical fields in the 
same entry. 

Default value: length = (no call forwarding defined). 

7.4.1 1 .5 Virtual contact list and call list per line 

The default behaviour of the "List access service" feature is to share all lists between all registered PPs, independently 
of the line attachments of the PPs. 

The current procedure allows to share virtually contact or call lists (missed calls, outgoing calls, incoming accepted 
calls, all calls lists) only between handsets attached to the same line. For a system implementing this procedure, it shall 
be possible to switch back dynamically to the default behavior. 
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After reading or searching entries, the PP shall filter the entries that are related to a given line thanks to the line 
identifier field. This way, the PP has a possibility to show to the user only the calls and contacts that are related to one 
line (including the contacts that are attached to all lines). 

7.4.12 Calling line identity restriction (CLIR) 



7.4.12.1 



Considerations 



The "Calling line identity restriction" feature defines procedures for CLIR as defined by 3GPP Technical specifications 
for Line identification supplementary services (see TS 122 081 [24]). 

This procedure allows a user to enable or to disable the presentation of its calling line identification when originating a 
call. When it is enabled, the originating network notifies the destination network that the calling party number is not 
allowed to be presented to the called party. If the called party subscribes to calling identification and the calling party 
has calling line identification restriction enabled, the called party shall receive the presentation indicator set to 
"presentation restricted" in the «CALLING-PARTY-NUMBER» IE of the CC-SETUP. In this case, the calling 
party's number will not be presented to the called party. 

The CLIR service may be provisioned in a permanent (for all outgoing calls) or a temporary mode (call by call basis). 

7.4.1 2.2 Permanent CLIR mode (all calls) 

This procedure allows a user to enable or to disable the presentation of its calling line identification for all following 
outgoing calls for a specified line. 

To enable (respectively disable) the permanent CLIR mode, the user shall set (respectively reset) the 'Permanent CLIR' 
field of the specified line in the "Line settings" list (see the "List access service" feature NG1.N.16). When this mode is 
enabled (respectively disabled), the FP shall invoke the permanent mode by sending the permanent CLIR activation 
(respectively deactivation) request to the network for the specified line. 

NOTE 1 : The current procedure does not state anything about the availability or not of the service on Network side. 



PP1 

Permanent CLIR 
invocation on line u 



FP 



Network 



line settings start session 



line u settings: 'Permanent CLIR' field set to '31 H' 



line settings end session 



Use of line u for sending 
a 'Permanent CLIR 
invocation' 




Figure 41 : Permanent CLIR mode invocation 

When the permanent mode is deactivated, it shall be always possible to use the temporary mode. 

NOTE 2: It should be noted that the permanent mode can also be provisioned by using the temporary mode for each 
call. 

When implementing the "Permanent CLIR mode (all calls)" procedure, the FP shall set bit a4Q of the "Extended higher 
layer capabiHties (part 2)" (see EN 300 175-5 [5], clause F.3). 



£75/ 



126 



ETSI TS 102 527-3 VI. 1.1 (2008-06) 



7.4.1 2.3 Temporary CLIR mode (call by call) 

This procedure allows a user to disable the presentation of its calling line identification at the time of the call request. 

If the user requests a temporary CLIR mode when originating a call, the PP shall insert before the telephone number in 
the «MULTI-KEYPAD» IE the CLIR invocation temporary digits sequence. 



PP1 

Temporary CLIR 
invocation on line u 

-I- 



FP 



Network 



if CO-SETUP is used: 



CC-SETUP 



« MULTI-KEYPAD, < Keypad info = 'CLIR invocation' : 



if CC-INFO is used: 



« MULTI-KEYPAD, < Keypad info = 'CLIR invocation' > :■> 



CC-SETUP 



CC-INFO 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > >: 



Use of line u for calling 
'CLIR invocation + 
called number' 




Figure 42: Temporary CLIR mode invocation 

A temporary CLIR request shall override a permanent deactivated CLIR mode. 

NOTE 1 : It should be noted that the temporary mode can also be provisioned directly by the user by dialling the 
CLIR temporary digits sequence. 

NOTE 2: As the network temporary CLIR invocation digits sequence is network dependent, the sequence should be 
configurable on PP side. 

7.5 Data Link Control (DLC) layer procedures 

This clause specifies the additional DLC layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 

7.5.1 DLC services 

The requirements of TS 102 527-1 [21], clause 7.5.1 shall apply. 

7.6 IVIedium Access Control (MAC) layer procedures 

This clause specifies the additional MAC layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 

7.6.1 MAC services 

The requirements of TS 102 527-1 [21], clause 7.6.1 shall apply. 
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7.6.2 Frame formats and multiplexers 

The requirements of TS 102 527-1 [21], clause 7.6.2 shall apply. 

7.6.3 Downlink broadcast 

7.6.3.1 Nt message 

The requirements of TS 102 527-1 [21], clause 7.6.3.1 shall apply. 

7.6.3.2 Qt - static system information 

The requirements of TS 102 527-1 [21], clause 7.6.3.2 shall apply. 

7.6.3.3 Qt - Fixed Part capabilities 

The requirements of TS 102 527-1 [21], clause 7.6.3.3 shall apply. 

Higher layer information: The management entity in the FP supplies the MAC layer with a 16-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits <a32> to <a47> of the Qt message. At the PT 
the MAC layer passes the 16 bits out through the ME SAP to the management entity. 

For the setting of the higher layer information bits see clause 7.3.9.1 of TS 102 527-1 [21]. 

7.6.3.4 Qt - Extended Fixed Part capabilities 

The requirements of TS 102 527-1 [21], clause 7.6.3.4 shall apply. 

Higher layer information: The management entity in the FP supplies the MAC layer with a 23-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits <a25> to <a47> of the Qt message. At the PT 
the MAC layer passes the 24 bits out through the ME SAP to the management entity. 

No higher layer information for New Generation DECT; parts 1 or 3 is broadcasted in Qt - Extended Fixed part 
capabilities. 



7.6.3.5 



Qt - Extended Fixed Part capabilities part 2 



The FT shall be capable of sending and the PT shall be capable of receiving and processing the Qt message as defined 
in EN 300 175-3 [3], clause 7.2.3.1 1 with the following values. 

Table 60: Values used within Extended FP capabilities part 2 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


«FP capabilities» 


<Qh> 


C 




<a12> 


1 


Long slot j=640 


<a13> 


0,1 


Long slot j=672 (if supported) 


<a23> 


0,1 


"no emission" mode: preferred carrier 
number mode (CN) 



Setting of bit Sj^ : "no emission mode" 

^23 ~ 1 • variable preferred CN /every CN possible. 
a23 = 0: fixed preferred CN. 
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The preferred carrier number is selected and broadcasted by the FT (PT broadcast info). 
FT: 

if (a23 = 1 ), then DummyPointer-wakeups on all carriers should be done after reset; 

if (ajj = ), then DummyPointer-wakeup only on the known preferred carrier should be done after reset. 
PT: 

check capability "no emission" mode: preferred carrier number mode; 

if (ajj = 1 ), then DummyRequest-wakeups on all carriers should be done after reset or asynchronous 
mode; 

if (a23 = ), then DummyRequest-wakeup only on the known preferred carrier should be done after reset 
or asynchronous mode. 

Higher layer information: The management entity in the FP supplies the MAC layer with a 24-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits <a24> to <a47> of the Qt message. At the PT 
the MAC layer passes the 24 bits out through the ME SAP to the management entity. 

For the setting of the higher layer information bits see clause 7.4.9.2.2. 

7.6.3.6 Qt - SARI list contents 

The requirements of TS 102 527-1 [21], clause 7.6.3.6 shall apply. 

7.6.4 Paging broadcast 

The requirements of TS 102 527-1 [21], clause 7.6.4 shall apply. 

7.6.5 "no-emision" mode 

The requirements of EN 300 175-3 [3], clauses 7.1.2, 7.2.3.11, 7.2.4.3, 7.3.5.3, 9.4 and 11.11 shall apply. 

7.7 Physical layer (PHL) requirements 

7.7.1 Modulation 

The FT and PT shall support 2 level Gaussian Frequency Shift Keying (GFSK) modulation as defined by 

EN 300 175-2 [2], clause 5. 

7.7.2 Slot type (Physical packets) 

The requirements of TS 102 527-1 [21], clause 7.7.2 shall apply. 

7.8 Requirements regarding the speech transmission 
7.8.1 General 

The requirements of TS 102 527-1 [21], clause 7.8.1 shall apply. 
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7.8.2 Speech codecs 

The requirements of TS 102 527-1 [21], clause 7.8.2 shall apply. 

7.8.3 Audio performance requirements 

The requirements of TS 102 527-1 [21], clause 7.8.3 shall apply. The status of each feature shall be as defined by 
tables 8 (clause 6.8) and 2 (clause 6.3) of the present document. 

7.9 Management procedures 

All procedures described in GAP (EN 300 444 [12], clause 13) shall be supported. Higher layer capability FP broadcast 
shall be set as described in clause 7.4.9.2 of the present document. 

7.10 Application procedures 

This clause specifies the additional application layer procedures, messages and information elements required in New 
Generation DECT Extended Wideband Speech Services not described in TS 102 527-1 [21] or in EN 300 444 [12] 
(GAP), or incorporating modifications to the description given in these specifications. 

7.1 0.1 Easy PIN code and easy pairing registration 

The "Easy PIN code registration" and "Easy pairing registration" features use common procedures (see clause 7.10.1.3) 
and specific procedures (see clauses 7.10.1.1 and 7.10.1.2 respectively). 

7.10.1.1 Easy PIN code registration 

7.10.1.1.1 Searching mode and PIN code requests 

The access rights procedure triggered by the user on the PP causes it to actively search for a FP broadcasting 'Access 
Rights supported attributes' capability (i.e. Extended Fixed part capability bit a44 = 1, see EN 300 444 [12], annex A 
(informative): PP locking procedure for on-air subscription procedure). The searching mode shall be limited by the 
timer P<AP.02>. 

When a FP is found in subscription mode, the PP shall prompt the user to enter the PIN code. After PIN entering, the PP 
shall start the access rights procedure using the PIN code value for the authentication code. 

NOTEl: When performing easy PIN code registration, it is assumed that the PP is in close proximity to the FP, and 
therefore the PP will receive a stronger signal from that FP. The PP can use RSSl readings to speed-up 
the search for the desired FP. For example: 

1 - Measure the RSSI level on each channel. 

2 - Synchronize on the FP with the highest RSSl value. 

3 - Wait for the a44 bit to check if it is set. 

4a - If a44 is set, start the access rights procedure. 

4b - If a44 is not set, put the RFPI on a barred list and go to step 2 (or 1) to find other FP. 

NOTE 2: It is recommended to request the PIN code entering after locking to a FP in subscription mode, because 
this procedure may be common with easy pairing search mode request procedure (see clause 7.10.4). 
Nevertheless it can be done before. 

NOTE 3: For security purposes, it is recommended to use a PIN value different from default '0000' value. In this 
case it could be convenient to indicate the device PIN value with a sticker on the FP. It could also be 
recommended to change the PIN value in the user manual. 
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PIN code as 
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FP-IVIAC 
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ACCESS-RIGHTS-REQ 



KEY-ALLOCATE 
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AUTHENTICATE-REPLY 



ACCESS-RIGHTS-ACCEPT 



Qh=3 (Access riglits supported=0) 
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Figure 43: Easy PIN-code registration mode 



7.1 0.1 .2 Easy pairing registration 



7.10.1.2.1 



Easy pairing registration description 



Easy pairing feature simplifies the registration process by not requesting any PIN code to the user when the PIN code is 
set to default "0000" value. 

When feature is implemented, related procedures shall be valid at first power ON of a non registered handset and at any 
additional further registrations. 

The PP will systematically try to register with the default "0000" PIN-code. In case of failure, the PP will automatically 
switch back to the easy PIN code registration feature process and corresponding procedures. 

From security point of view, successful easy pairing is equivalent to default 0000 PIN-code registration which is less 
secure than any non 0000 PIN code registration. As a consequence, for easy pairing registration, the user should be 
instructed to monitor the registration user feedback (see clause 7.10.6). 

As additional security and for user convenience it is recommended to use the "Base station name selection" 
(clause 7. 10.7). This allows checking that registration of a PP is ongoing on the correct FP. 

The 'Easy pairing feature support' capability bit shall be correctly managed by the FP. This allows to make the 
difference between an easy pairing capable FP and other FPs. 

7.10.1.2.2 Base station limited registration mode 

The FP shall have a physical or a logical button to trigger the access rights procedure. 

When the button is pressed on the FP, the FP shall set its broadcasting 'Access Rights supported attributes' capability bit 
to enable the on air subscription (see clause 7.4.9.1 "Higher layer information in FP broadcast" and EN 300 444 [12] 
clause 13.6 "Broadcast attributes management"). At the same time, the FP shall set the 'Easy pairing registration 
supported' capability bit (see clause 7.6.3.5 "Qt - Extended Fixed Part capabilities part 2"). 

These bits shall be set during timer F<AP.01>. When the access rights procedure is successfully completed, these bits 
shall be cleared. 

For security reasons, the FP shall perform no more than one successful access rights procedure during the subscription 
mode. 



7.10.1.2.3 



Searching mode request 



The access rights procedure triggering by the user on the PP causes it to actively search for a FP broadcasting 'Access 
Rights supported attributes' capability (i.e. Extended Fixed part capability bit a44 = 1, see EN 300 444 [12], annex A 
(informative): PP locking procedure for on-air subscription procedure). The searching mode shall be limited by the 
timer P<AP.02>. 
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When a FP is found in subscription mode, the PP shall start the access rights procedure using the '0000' value for the 
authentication code. If the FP rejects the access rights, the PP shall prompt the user to enter the PIN code. The PP shall 
then initiate a new access rights request with the same FP using the PIN entered value for the authentication code. 

NOTE: When performing easy pairing registration, it is assumed that the PP is in close proximity to the FP, and 
therefore the PP will receive a stronger signal from that FP. The PP can use RSSI readings to speed-up 
the search for the desired FP. For example: 

1 - Measure the RSSI level on each channel. 

2 - Synchronize on the FP with the highest RSSI value. 

3 - Wait for the a44 bit to check if it is set. 

4a - If a44 is set, start the access rights procedure. 

4b - If a44 is not set, put the RFPI on a barred list and go to step 2 (or 1) to find other FP. 
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FP-MAC 
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Use '0000' value •<- 
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.^ 



Qh=3 (Access rights supported=1) 
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ACCESS-RIGHTS-REQ 



KEY-ALLOCATE 



AUTH-REQUEST 



AUTHENTICATE-REPLY 



ACCESS-RIGHTS-ACCEPT 



Qh=3 (Access rights supported=0) 



^Qy^^Q (Easy pairing supported=0) 



-Push button 



V 



Within timer 
F<AP.01> 



Figure 44: Easy pairing when PIN is set to default '0000' value 
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-Push button 
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Figure 45: Easy pairing when PIN is not set to default '0000' value: switching back to PIN entry 

Backward compatibility management : when a PP is in front of a FP without easy pairing capability, here are three 
possible behaviours of the PP (among several others and left free to implementer): 

1) The PP uses the easy pairing feature, in case of failure, requests the PIN code, exactly as in front of a FP with 
easy pairing. The PP does not take into account the capability bit. This means easy pairing feature is always 
used on the PP independently of the FP type. 

2) The PP uses the easy pairing feature but in case of easy pairing failure, the PP uses the capability bit to warn 
the user that re-triggering of the FP registration button might be necessary before using the easy PIN code 
registration feature. This deals with the case where the FP might not remain in registration mode in case the PP 
easy pairing attempt fails (could occur on some GAP FP for example). 

3) The PP detects the absence of 'easy pairing registration supported' capability bit from the beginning and 
decides not to use the easy pairing feature but to use easy PIN code registration feature instead. This behaviour 
has the drawback not to use easy pairing. So it should be implemented only if behaviour 1 and 2 can not be 
implemented. 

7.10.1 .3 Common procedures to easy PIN code and easy pairing 



7.10.1.3.1 



Registration mode automatic access 



When a PP that it is not registered to any FP is powered on, the PP shall start in a mode where the user is directly 
invited to trigger the access rights procedure. Upon user acknowledge, the access right procedure shall start. 

It shall be possible for the user to leave this mode to switch back to idle mode. 

For any further registrations on the PP (additional registration to the initial one), the registration mode should also be 
easily accessible from the user point of view. 
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7.10.1.3.2 Base station name selection 

This clause applies only to PP with a display capability. 

The FP shall broadcast its name during the subscription mode. The name shall be composed of up to 17 characters to fit 
in a {CLMS -FIXED} message. The name could be set to the manufacturer and model of the phone by default (see 
note 1) and could be changed by the user to a friendly name. 

As soon as a FP with a44 set to 1 is found within the FP searching process based on the RSSI, the name shall be 
displayed by the PP. 

EXAMPLE 1 : The PP may display a list of FP names in subscription mode for selection by the user. 

EXAMPLE 2: The PP may display only the selected FP (taking into account the best RSSI indication for 
example). 

The PP will then start the access rights procedure with the selected FP (see clauses 7.10.2 or 7.10.5). The name shall be 
displayed by the PP with the result of the complete registration procedure. 

The FP shall transmit its name information frequently during the subscription mode (i.e. during timer F<AP.01>). At 
least, the first segment of the FP name shall be transmitted within one period of F<AP.03> after the FP capabilities 
information transmission in order to receive it very quickly on PP side. 

NOTE 1: When there are several FP of same type in range in subscription mode, this can be confusing. Therefore, it 
is recommended to set a unique name by default. For a DECT phone, the name could be composed of the 
phone model reference with the two last bytes of RFPI and indicated with a sticker on the FP. For a 
DECT FP integrated within a gateway /PBX, the name could be composed of the gateway/PBX model 
reference with additional unique identifier. 

NOTE 2: The PP should take into account the FPs not supporting the base name broadcasting (e.g. GAP or 

NG-DECT part 1 base stations). In that case, the PP may display a message like "Unknown" or the RFPI. 

NOTE 3: With this procedure, the overall process to select a base in registration mode is a little bit longer but it 
really improves the security. 
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FP name broadcasting is initiated by including the «NETWORK-Parameter» information element in the 

{CLMS -FIXED} message. The procedure to construct a multi-section {CLMS -FIXED} message shall be performed as 

defined in EN 300 175-5 [5], clause 8.3. 



PT-IWU 



PT 



MNCL UNIT DATA-req 



«NETWORK-parameter : 
Device Name» 



FT 



Qh.3 (Access rights supportecl=1) 



01 IVI.S-FIXFn 



Address section 

01 IVI.S-FIXFn 



Data section 1 

^ 0! IVI.S-FIXFn 



Data section 2 



IZ. 



Qh.3 (Access rights supportecl=0) 



FT-IWU 



MNCL UNIT DATA-rec 



«NETWORK-parameter = 
Device Name» 

Within timer 
F<AP.03> 



Registration 



mode 



Within timer 
F<AP.01> 



Figure 46: Base station name broadcasting 



Table 61 : Values used within the {CLMS-FIXED} message 1^* segment 



Information element 


Field within the 
information element 


Standard values 
within the field/IE 


Normative action/comment 


«A» 




1 


Address section 


«CLMS header» 




010 


Multiple sections/Standard 


«Address» 




CFFFH 


Connectionless Group TPUl 


«Protocol 
Discriminator» 


<Second Discriminator> 


000001 


DECT Information elements coding 


«Length ldentifier» 




Any 


Indicates implicitly the number of data 
sections to follow 



Table 62: Values used within the {CLMS-FIXED} message 2"^ segment 



Information element 


Field within the 
information element 


Standard values 
within the field/IE 


Normative action/comment 


«A» 







Data section 


«CLMS header» 




000 


Data section number - {1st) 


«DATA/Fill» 




41H 


NETWORK parameter (octet 1) 






Any < 20 


Length (octet 2) 






00010000 


Discriminator: Device name (octet 3) 






Name 


First character of name (octet 4) 
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Table 63: Values used within the {CLMS-FIXED} message k segment 



Information element 


Field within the 
information element 


Standard values 
within the field/IE 


Normative action/comment 


«A» 







Data section 


«CLMS header» 




K 


Data segment (k+1) 


«DATA/Fill» 




Name 








Name/Fill 








Name/Fill 








Name/Fill 





7.10.1.3.3 



Registration user feedback 



This clause applies only to FP with user signalling capability (for example a display, a LED or a buzzer). To improve 
the security, it is strongly recommended to support this feature both on the FP and the PP. 

The FP and the PP shall give a feedback to the user of the registration process through a user interface. 

The feedback given on the user interface of the PP and the FP shall be as a minimum the following status of the 
registration process with the following states: 

• Registration in progress state: 

Condition of entrance: the PP is looking for or is locked on a FP in subscription mode and the protocol is 
exchanging messages. 

Recommended user action: wait for protocol to finish. 

• Registration error state: 

Condition of entrance: some error occurred, such as failed to find a peer device, or to complete the access 
rights procedure (e.g. authentication failed). 

Recommended user action: wait then try again. 

• Registration success state: 

Condition of entrance: protocol procedure is complete and successful. 

Recommended user action: try to make an outgoing call request. 

The proposed user feedback with corresponding user interface allows user to check that registration on the correct FP 
was successful. This is an additional security especially in the case of the easy pairing procedure which is less secure 
than the PIN-code registration procedure. 

The user should be aware that during the registration mode unwanted PP could join the FP. The user should be 
instructed to monitor the user interface, especially to check the success indication on both sides for security 
considerations. This verification will prevent the PP from joining a FP that was not selected or to prevent an other PP 
from joining the selected FP. 

Type of user interface is left free to implementers. For example, the user interface could be a display on the PP side and 
a LED on the FP side. It could also be an audio tone indication or any other richer user interface (displays on both sides 
for example). 

7.10.2 Handset locator 

On FP side, a software or hardware button shall trigger this procedure. 

The FP shall present an incoming external call to all PPs registered to the FP. Incoming call used at NWK level is the 
GAP NWK feature N8 "Incoming call". The FP shall send the information element «Calling Party Name» with the 
<Presentation indicator> field set to 'Handset locator' value. 

On PP side, the call shall be presented as an incoming call. If PP has ringing capabilities enabled, the PP shall ring. 
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NOTE 1 : It is recommended that the FP sends a CNIP with a name related to the current procedure, for example 
"Handset locator". 

NOTE 2: The 'Handset locator' value of <Presentation indicator> field in CNIP might be used by the PP to trigger 
the ringing even if it is disabled, or to increase the ringer volume in that particular case. 

Table 64: Values used within the {CC-SETUP} or {CC-INFO} message 
for handset locator internal call CNIP 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Calling party 
name» 








<Presentation indicator> 


11 


Handset locator 


<Used Alphabet> 


All 




<Screening indicator> 


All 




<Calling party name> 


All 


'Handset locator' for example 



The procedure is stopped when incoming call is accepted by one of the PPs. In this case, the FP shall immediately 
release the call on this particular PP and stops incoming call presentation to other PPs. 

NOTE 3: Other possible stops of the procedure are out of the scope of the current specification. For example the 
procedure could also be stopped: 

■ by pressing the button again on the FP side; 

■ by using a timer mechanism on FP side. 

NOTE 4: The way the call is accepted on the PP is out of the scope of the present document. For example only the 
call key could accept the incoming call. 
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-^ 


CC-SETUP «CNIP=Hanset locator» 


CC-SETUP «CNIP=Hanset locator» 


PP1 is locc 


ted by user 
CC-CONNECT 


CC-RELEASE 


CC-RELEASE-COM 


CC-RELEASE 







Figure 47: Handset locator example where PP1 is located 

NOTE 5: The Call Control message sequence in figure 47 should be understood as an example. The real sequences 
may also contain different Call Control messages or Call Control messages in another order or Call 
Control messages with other contents. 
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Annex A (normative): 
System parameters 

A.1 Application timers 

<AP.01> Subscription mode timer. 

FT value: 120 seconds. 

PT value: Not used. 

Start: Subscription mode has been requested by the user: set a44 "access rights supported" bit and "Easy 

pairing registration supported" a37 bit. 

Stop: As soon as on-air subscription procedure is successful, clear a44 "access rights supported" bit and 

"Easy pairing registration supported" a37 bit. 

<AP.02> Searching mode timer. 

FT value: Not used. 

PT value: 120 seconds. 

Start: Searching mode has been requested by the user: listen and wait for a44 "access rights supported" 

bit. 

Stop: As soon a as on-air subscription procedure is successful. 

<AP.03> Base station name broadcasting timer. 

FT value: 160 ms. 

PT value: Not used. 

Start: Base station name broadcasting occurrence (Higher layer capabilities FP broadcast sent). 

Stop: The first segment of the FP name is sent. 
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Annex B (normative): 
Procedure diagrams 



The following diagrams depict basic sequences that illustrate the text of present document. 

The Call Control message sequences in the following diagrams shall be understood as examples. The sequences may 
also contain different Call Control messages or Call Control messages in another order or Call Control messages with 
other contents. 

EXAMPLE: CC-ALERTING and CC-CALL PROCEEDING are sometimes not mentioned although they are 
allowed in the sequences. 



B.1 Events notification diagrams 

The following flowcharts are very basic sequences. See also annex C (especially clauses C.2.4 and C.2.5) for more 
complete examples of notifications. 

For clarity of the following flowcharts, «Call information» IE including call identifiers and line identifiers does not 
appear in some of the CC messages that must convey it. Please note that they should not be omitted when implementing 
equivalent cases. 



B.1 .1 Event notification when there is no existing connection 

Use case: FP wants to send an event notification and there is no existing connection : use the CLSS procedure (page the 
PP and setup the bearer). 



PP 



FP 



NWK MAC 



MAC NWK 
LCE-REQUEST-PAGE 



access_request 



bearer confirm 



« CALL INFORMAt 

Facility 
«Events notification», «CALL-INFORMATION, 

Lineld» 



Figure B.1 : Event notification when there is no existing connection 

NOTE: Line identifier may be equal to 'all lines' value. 
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B.1 .2 Event notification during existing connection 

Use case: FP wants to send an event notification when the PP is on communication : use the existing connection. 



PP 



CALL 



FP 



Facility 



«Events notification», «CALL- 
INFORIVIATION, Lineld» 



Figure B.2: Event notification during existing connection 

NOTE: Line identifier may be equal to 'all lines' value. 

B.1 .3 Event notification when the PP is switched on 

Use case: FP has wanted to send an event notification when PP was switched ofl", PP is switched on : use the location 
registration connection. 



PP 



FP 



LOCATE-REQUEST 



LOCATE-ACCEPT 



Facility 



«Events notification», «CALL-INFORMATION, 

Lineld»| 



Figure B.3: Event notification when the PP is switched on 

NOTE: Line identifier may be equal to 'all lines' value. 
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B.1 .4 Event notification using call connection 

Use case: FP has wanted to send an event notification when PP was not in range, PP sends a CC-SETUP : use the call 
connection. 



PP 



FP 



CC-SETUP 



CC-CONNECT 



Facility 



«Events notification», «CALL-INFORI\/IATION, 

Lineld»| 



Figure B.4: Event notification using call connection 

NOTE: Line identifier may be equal to 'all lines' value. 

B.1 .5 Event notification for "IVIissed call notification" 

Use case: Missed call notification message sequence. 



PP 



Alerting 



User accesses 
missed calls list 



FP 



CC-SETUP 




«CLIP» 
CC-ALERTING 




CC-RELEASE 


^ « RELEASE REASON, » 
CC-RELEASE-COM 




« RELEASE REASON » 

FACILITY 



« EVENTS NOTI FICATIONS, < Missed call, Voice, 1 >, 

< List change indication. Missed call list, 1 > » 

« CALL-INFORMATION », Linedid » 



End of incoming call 



Missed calls list consultation using list access feature 
(Read or edit command) 



FACILITY 



« EVENTS NOTIFICATIONS, <Missed call. Voice, > » 
« CALL-INFORMATION, Lineld » 



Figure B.5: Missed call notification 

NOTE: See also clause C.2.4 for more detailed flowcharts including line identifiers and call identifiers. 
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B.2 Date-time synchronization diagrams 

These flowcharts depicts the date and time synchronization feature, but only in the cases where the FP sets the date and 
time of the PP. If the DECT system implements this feature, the FP behaviour shall follow one of the possible use cases 
listed hereafter. Please note some flexibility is allowed concerning the the CC messages. 

For clarity of the following flowcharts the «Call information» IE including call identifier does not appear in the CC 
messages that must convey it. Please note that it should not be omitted when implementing equivalent cases. 

EXAMPLE: The call identifier must be assigned by the FP after CC-SETUP message. 

B.2.1 Date-time synchronization when there is no existing 
connection 

Use case: FP wants to send a time and date synchronization and there is no existing connection: use the CLSS 
procedure (page the PP and setup the bearer). 



PP 



FP 



NWK MAC 



MAC NWK 
LCE-REQUEST-PAGE 



access_request 



bearer confirm 



FACILITY «Time-Date » 



Figure B.6: Date-time synchronization when there is no existing connection 

B.2. 2 Date-time synchronization during existing connection 

Use case: FP wants to send a time and date synchronization when the PP is on communication : use the existing 
connection. 



PP 



FP 



FACILITY « Time- Date : 



Figure B.7: Date-time synchronization during existing connection 
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B.2.3 Date-time synchronization when the PP is switched on 

Use case: FP has wanted to send a time and date synchronization when PP was switched off, PP is switched on : use the 
location registration connection. 



PP 



FP 



LOCATE-REQUEST 



LOCATE-ACCEPT 



FACILITY « Time-Date » 



Figure B.8: Date-time synchronization when the PP is switched on 

B.2.4 Date-time synchronization using call connection 

Use case: FP has wanted to send a time and date synchronization when PP was not in range, PP sends a CC-SETUP : 
use the call connection. 



PP 



FP 



CC-SETUP 



CC-CONNECT 



FACILITY « Time-Date 



Figure B.9: Date-time synchronization using call connection 

NOTE: The line identifier is not represented here. Note that it is anyway only relevant if the synchronization is 
done in the context of an external call. 



B.3 List access service basic sequence diagrams 

For clarity of the following flowcharts, «Call information» IE including call identifiers and line identifiers does not 
appear in some of the CC messages that must convey it. Please note that they should not be omitted when implementing 
equivalent cases. 
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B.3.1 Start/end session when PP is in idle mode 



PT 



FT 



Direct PT initiated linl< establishment 



CC-SETUP 



IE « Basic Service < Call Class=Normal call setup > » 
CC-CALL-PROC 



IWU-lnfo 



IE « IWU to IWU= start session, list identifier, sorting field identifiers » 

IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier. Total number, 
sorting field identifiers » 



list access 



IWU-lnfo 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 



CC-RELEASE 



CC-RELEASE-COM 



Figure B.10: List access: start/end session when PP is in idle mode 
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B.3.2 Start/end session when a call is already established to PP 



PT 



FT 



call established 



IWU-lnfo 



IE « IWU to IWU= start session, list identifier, sorting field identifiers » 



IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier. Total number, 
sorting field identifiers » 



list access 



IWU-lnfo 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 



Figure B.11 : List access: start/end session when a call is already established to PP 

NOTE: See also diagrams in clause C.6 for examples on list access and voice calls flowcharts. 



B.3.3 Query supported entry fields 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= query supported entry fields, session identifier » 



IWU-lnfo 



IE « IWU to IWU= query supported entry fields confirm, session identifier, list 
of supported entry field identifiers» 



Figure B.12: List access: query supported entry fields 
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B.3.4 Read entries 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 

IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 



Figure B.13: List access: read entries 
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B.3.5 Edit entry 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= edit entry, session id, entry identifier, list of field identifiers » 



IWU-lnfo 



IE « IWU to IWU= edit entry confirm, session id » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 



Figure B.I 4: List access: edit entry 
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B.3.6 Save entry 



PT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= save entry, session id, entry identifier » 



IWU-lnfo 



IE « IWU to IWU= data pacl<et, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part l< » 



IWU-lnfo 



IE « IWU to IWU= save entry confirm, session id, start index, 
entry identifier, position index » 

FACILITY (optional, depending on list) 



FT 



« EVENTS NOTIFICATION, List change notification », 
« CALL INFORMATION, Line Id » 



Figure B.15: List access: save entry 

NOTE: Alternatively the FACILITY message might be sent after terminating the list access session. 



B.3.7 Delete entry 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= delete entry, session id, entry identifier » 



IWU-lnfo 



IE « IWU to IWU= delete entry confirm, session id, total number » 



Figure B.16: List access: delete entry 

NOTE: The list has changed once this procedure has been performed. PP should read list again starting from 
index of the first entry which was deleted. 
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B.3.8 Delete list 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= delete list, session id » 



IWU-lnfo 



IE « IWU to IWU= delete list confirm, session id : 



Figure B.17: List access: delete list 



B.3.9 Search entries 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= search entries, session id, searched value, counter, list of 

field identifiers » 



IWU-lnfo 



IE « IWU to IWU= search entries confirm, session id, start index, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 



Figure B.I 8: List access: search entries 
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Annex C (informative): 

Recommended implementation of procedures 



C.1 General 



In the following clauses, several examples for generic sequence charts are depicted. 

It has to be noted that the sequences are only examples, it cannot be mandatory that the message flows shall always be 
exactly in the described way. However it is recommended to follow the examples where possible in order to ensure 
interoperability. 



C.2 Multiple lines diagrams 



The diagrams of this clause document the "Multiple lines" feature. This feature can be used when at least the FP 
implements it. For the PP, implementing this feature means that it is aware of multiple attachments, and proposes an 
adapted MMI. 

However a PP may be attached to several lines without being aware of it, i.e. not implementing the "Multiple lines" 
feature. Such a PP would use e.g. "FP-managed line selection" for outgoing calls, and would receive calls from these 
lines at the price for the user of not knowing from which line an incoming call arrives (unless asking the calling user). 

The "Line identification" feature is an independent feature on PP side, but a pre-requisite on FP side. Implementing it 
on PP side (recommended) however allows the user to place a call on line k by keyboarding '#k' before the called 
number, or by introducing the 'k' value through a dedicated MMI. It also allows the user to know in advance on which 
line a call is received through display. However, such a PP still cannot propose a menu with the set of attached lines 
presented and to choose from. 

If the PP now implements the "List access" feature, in addition to the "Line identification" feature, it has got virtually 
anything it needs to implement the "Multiple lines" feature, and implenting it at this stage is only a matter of MMI 
implementation. 

C.2.1 Attaching a new PP to one or several lines 

Use case: the user hast just registered a new PP, then the user is invited to select the line(s) to which the new PP is 
attached to (PP managed attachment). This use case can also be used later to change the handsets attachment to the 
lines. 

We assume that the new registered PP is the terminal number 'm'. 
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PP 



ACCESS-RIGHTS-REQUEST 



FP 

■> 



ACCESS-RIGHTS-ACCEPT 



LOCATE- REQUEST 



LQCATE-ACCEPT 



TEMPORARY-IDENDITY-ASSIGN-ACK < TPUl ldN=m > 



Line settings start session. 'Total number of entries' = N (lines) 



handsets' field of each line for the new registered PP: 

IWU-INFQ 




IE « IWU to IWU= read entries, session id, start index=n, counte r=forward/1, 
list of field identifiers = Line Id id. Line name id. Attached handsets id » 

IWU-INFO 



IE « IWU to IWU= read entries confirm, session id, counter=1 » 
IWU-INFO 



IE « IWU to IWU= data packet, session id, content part = n* entry content » 

IWU-INFO 



IE « IWU to IWU= edit entry, session id, entry identifier = entry id n, 
list of field identifiers= Line Id id, Line name id. Attached handsets id » 

IWU-INFQ 



for(n€ 1.. N) 



IE « IWU to IWU= edit entry confirm, session id, start index = n » 
IWU-INFO 



IE « IWU to IWU= data packet last, session id, content part= n* entry content ; 



user may update the 'Attached handsets' field for n* line in line settings list 
to attach the new registered PP to the n* line 



IWU-INFO 



IE « IWU to IWU= save entry, session id, entry identifier= entry id n » 
IWU-INFO 



IE « IWU to IWU= data packet last, session id, content part= n* entry updated » 

IWU-INFQ 



IE « IWU to IWU= save e ntry confirm, session id, entry identifier = entry id n, 

start index » 



FP notifie s list change notification to all PPs attached to the line n 



line settings end session 



Figure C.I : Attaching a new PP to one or several lines 

NOTE 1 : The above diagram assumes that only one "data packet" command is necessary for reading one entry 
content, i.e. the 'data packet last' command is received directly. 

NOTE 2: As an alternative, all entries in the "Line settings" list could be read all at once with one read entries 
command. 
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C.2.2 Outgoing first call on a line 

For each use case, two sub use cases at least are handled: Line identification by PP, or FP managed line selection. 

C. 2.2.1 PP attached to 1 line 



C.2.2.1 .1 Line identification by "mono-line" PP 

See below, clauses C.2.2. 2.1, C.2.2. 2. 2 and C.2.2. 2. 3, as there is no difference from the case when a PP is attached to 
several lines (the only line-id still must be sent at call setup by a PP attached to only one line). 

C.2.2.1 .2 No line identification by "mono-line" PP: not relevant 

"FP-managed line selection" is not recommended for a PP attached to only one line, which must systematically send the 
line-id. 

C. 2.2.2 PP attached to several lines 

Clauses C.2.2. 2.1, C.2.2. 2. 2 and C.2.2. 2. 3 implement variants of the same use case: the PP implements the "Line 
identification" feature and sends the line-id when setting up the call. Clause C.2.2. 2. 3 in addition presents the case 
where the PP sends the called number before the call-id is received (pre-dialling and similar use cases). 

Clause C.2.2. 2.4 documents call by call FP-managed line selection and clause C. 2. 2.2.5 permanent FP managed line 
selection, useful for example for the case a PP, although attached to several lines, always uses the same line for 
outgoing calls. 

C.2.2.2.1 Line identification by PP using «CALL-INFORMATION» 

Use case 1 : the PP selects a line on a call-by-call basis using «CALL-INFORMATION» IE. 

PP FP Network 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

CC-INFO 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 
» 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 

« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call-Id 1' > 



Use of line u 

for calling 

'called number' 




Figure C.2: Line identification by PP using «CALL-INFORI\/!ATION» 
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NOTE 1 : The PP in this diagram is also supposed to implement "Line identification" (see CC-SETUP and 
CC-INFO for called number) and "Call identification" (see CC-INFO for called number). 

NOTE 2: As "Call identification" is mandatory for NG PART3 FPs, the call identifier notification is represented, 
although it is somehow independent of the "Multiple lines" feature. The line identifier is repeated in the 
«CALL-INFORMATION» IE used for that notification as a result of the "call information 
completeness principle". 

C.2.2.2.2 Line identification by PP using the «MULTI-KEYPAD» 

Use case: the PP selects a line on a call-by-call basis using « MULTI-KEYPAD » IE (e.g. the user used the keyboard 
to select the line instead of the dedicated MMI). 



PP 

attached to line u e 1..9 



FP 



Network 



CC-SETUP 




k. 


« MULTI-KEYPAD, < Keypad info = 


'23 3u'H > » 




CC-INFO 

■^ 







« CALL-INFORIVIATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 
» 

CC-INFO 



« MULTI-KEYPAD, < Kevoad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 



Use of line u 

for calling 

'called number' 




Figure C.3: Line identification by PP using «MULTI-KEYPAD» 

NOTE 1: Restriction to [0..9] interval for the line id value is in place here because «MULTI-KEYPAD» is used 
for sending the line id. 

NOTE 2: As "Call identification" is mandatory for Part 3 FPs, the call identifier notification is represented, 

although it is somehow independent of the "Multiple lines" feature. The line identifier is repeated in the 
«CALL-INFORMATION» IE used for that notification as a result of the call information 
completeness principle". 

C.2.2.2.3 Line identification by PP immediately followed by call number 
(e.g. pre-dialling) 

Use case: the PP selects a line on a call-by-call basis (using here « CALL-INFORMATION» IE), and immediately 
sends the called number, without waiting for the call id. This use case applies when pre-dialling is used, when 
re-dialling is used, or when the call is placed after phone book look-up. 

NOTE: Use of the «CALLED PARTY NUMBER» in the CC-SETUP is not considered, as it is not used in 
GAP and part 3 relies on GAP. 
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PP 



FP 



Network 



CC-SETUP 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 
» 

CC-INFO 



« IVIULTI-KEYPAD, < Keypad info = 'called number' > » 



CC-INFO 



« CALL-INFORIVIATION, 



< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 



ifiertype = 'Line identifier' > 

tier subtype = ' Line identifier for external calls' > 

ifier value = u > 

ifier type = 'Call identifier' > 

tier subtype = 'Call identifier' > 

ifier value = 'call-id 1' > 



Use of line u 

for calling 

'called number' 




Figure C.4: Line identification by PP immediately followed by call number 

C. 2. 2. 2.4 No line identification by PP: FP managed line selection 

Use case: a line is selected by the FP using the 'Attached handsets' parameter of lines settings. For example, a line is 
selected by configuration for all outgoing calls, or lines are prioritized by configuration and the first free line is used, 
etc. 



PP 



FP 



Network 



CC-SETUP 



CC-INFO 



« CALL-INFORIVIATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier > 

< Identifier value = 'call-id 1' > 
» 

CC-INFO 



« IVIULTI-KEYPAD, < Keypad info = 'called number' > » 



CC-INFO 



Selects u among 
lines attached to PP 



« CALL-INFORIVIATION, 



< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 



tier type = 'Line identifier' > 

tier subtype = 'Line identifier for external calls' > 

tier value = u > 

tier type = 'Call identifier' > 

tier subtype = 'Call identifier' > 

tier value = 'call-id 1' > 



Use of line u 

for calling 

'called number' 



Figure C.5: No line identification by PP: FP managed line selection 
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NOTE: The sequence of messages above is also used for NG DECT PPs that do not implement the "Multiple 
lines" feature (Part 1 PPs or Part 3 PPs not implementing the feature). However, such PPs could ignore 
the line-id received. 

C.2.2.2.5 No line identification by PP and permanent FP-managed line selection 

Use case: the PP always uses the same line for outgoing call (e.g. the line is selected by configuration). In this case, the 
FP may send the line-id as soon as possible, i.e. together with the call-id. 



PP 



FP 



Outgoing 

parallel call 

initiation 



Line selected for the call 
if external 



CC-SETUP 



CC-INFO 



« CALL-INFORIVIATION, 



Identi 
Identi 
Identi 
Identi 
Identi 
Identi 



fier type = 'Line identifier' > 

fier subtype = 'Line identifier for external calls' > 

fier value = u > 

fier type = 'Call identifier' > 

fier subtype = 'Call identifier' > 

fier value = 'call-id 1' > 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION, 



< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 



fier type = 'Line identifier' > 

fier subtype = 'Line identifier for external calls' > 

fier value = u > 

fier type = 'Call identifier' > 

fier subtype = 'Call identifier' > 

fier value = 'call-id 1' > 



Figure C.6: No line identification by PP and permanent FP-managed line selection 

NOTE: This use case does not apply to a PPs attached to a single line: as a rule, a PP implementing "Line 

identification" should always perform line selection unless it uses "FP-managed line selection" in the 
purpose of simplifying the user experience. If attached to a single line, it can send the line-id without user 
intervention so that the user experience cannot be simplified further. 
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C.2.2.3 GAPPP 

C. 2. 2. 3.1 Line identification by GAP PP with backward compatible mechanism 

Use case: the PP selects a line using « MULTI-KEYPAD » IE. A GAP handset will not receive any 
«CALL-INFORMATION» element. 



PP 

attached to line u e 1..9 



FP 



CC-SETUP 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = '23 3u'H > 

< Keypad info = 'called number' > 
» 



Network 



Use of line u 

for calling 

'called number' 




Figure C.7: Line identification by GAP PP withi backward compatible mechianism 

C.2.2.3. 2 No line identification by GAP PP: FP managed line selection 

Use case: the line is selected by the FP using the 'Attached handsets' parameter of lines settings. A GAP handset will not 
receive any «CALL-INFORMATION» element. 



PP 

attached to line u e 1..9 



FP 



CC-SETUP 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 



Selects u among 
lines attached to PP 



Network 



Use of line u 

for calling 

'called number' 




Figure C.8: No line identification by GAP PP: FP managed line selection 

C.2.2.4 NG-DECT Part 1 PPs 

0.2.2.4.1 Line identification by Part 1 PP with backward compatible mechanism 

"Part 1 PP" means a PP compliant with TS 102 527-1 [21]. 

Use case: the Part 1 PP selects a line using « MULTI-KEYPAD » IE, but however receives the 
«CALL-INFORMATION» element from the FP (and ignores it). 
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PP 

attached to line u e 1..9 



FP 



Network 



CC-SETUP 



« MULTI-KEYPAD, < Keypad info : 
CC-INFO 



'23 3u'H > » 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 
» 

CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 



Use of line u 

for calling 

'called number' 




Figure C.9: Line identification by Part 1 PP with bacltward compatible mechanism 

NOTE: Figure C.9 is also valid for a Part 3 non-multiple line PP (i.e. not implementing the "Multiple lines" 
feature). If such a PP however implements the "Line identification" feature, it could use a 
«CALL-INFORMATION» instead of sending the keypad information '#u'. See the introduction of 
clause C.2 for information about what distinguishes such a Part 3 PP from a real "Multiple lines" PP. 

C. 2. 2.4. 2 No line identification by Part 1 PP: FP managed line selection 

See clause C.2. 2. 2.4, "No line identification by PP: FP managed line selection", which also applies here. 

C.2. 3 First incoming call on a line 
C. 2.3.1 PP attached to 1 line 

See below, clause C.2. 3. 2, PP attached to several lines, as there is no difference with the case when a PP is attached to 
several lines. 

C. 2.3.2 PP attached to several lines 

Use case: the PP is attached to several lines. An incoming call on line u is presented. 



PP 

attached at least to 
line u 



CC-SETUP 




Network 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = = 'call-id 1' > 



Figure CIO: First incoming call, PP attached to several lines 



Incoming call to line u 
from 'calling number' 
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C.2.4 Missed call on a specific line 



Use case: the PP is attached to several lines. Missed call list is implemented. An incoming call on line u is not 
answered. Missed call and missed call list update notifications are sent just after the incoming call release. 



PP 

attached at least to 
line u 



FP 



Network 



CC-SETUP 



« CALL-INFORMATION, 



< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 



tier type = 'Line identifier' > 

tier subtype = 'Line identifier for external calls' > 

fier value = u > 

fier type = 'Call identifier' > 

fier subtype = 'Call identifier' > 

fier value = 'call-id 1' > 

CC-RELEASE 



CC-RELEASE-COIVI 



FACILITY 




Incoming call to line u 
from 'calling number' 



« EVENTS-NOTIFICATION, 

< Event type = 'Missed call' > , 

< Event sub type = 'Voice' > 

< Event multiplicity = 1 > 

< Event type = 'List change indication' > , 

< Event sub type = 'Missed call list' > 

< Event multiplicity = 'number of missed called in the missed calls list' > 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Relating-to line identifier' > 

< Identifier value = u > 



Figure C.1 1 : IVIissed call on a specific line 

NOTE: The list change indication for the Missed call list is optional. 
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C.2.5 Voice message waiting indication on a specific line 



Use case: a voice message has been left in the voice mailbox of line u, a voice message waiting indication is sent to 
each PP attached to this line. 



PP 

attached at least to 
line u 



FACILITY 



FP 



Network 



« EVENTS-NOTIFICATION, 

< Event type = 'Message waiting'>, 

< Event sub type = 'Voice' > 

< Event multiplicity = 1 > 

<< CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Relating-to line identifier' > 

< Identifier value = u > 




Voice message waiting 
indication on line u 



Figure C.12: Voice message waiting indication on a specific line 



C.3 IVIultiple calls diagrams 

C.3.1 First incoming call on the line or system 

Use case: the PP is attached to a multi-call line. An incoming call is presented to the line. 



PP 

attached to 
multiple-call line u 



FP 



Network 



CC-SETUP 




Incoming call from 
'calling number' 



« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = u > 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call-id 1 '> 



Figure C.13: First incoming call on the line or system 

NOTE: Although somehow independent of the "Call identification" feature, the line identifier notification is also 
represented, as "Line identification" is mandatory for Part 3 FPs. 

C.3. 2 Second incoming call on the line or system 

Use case: the PPs are attached to a multi-call line. A call is on going from PPl which implements the "Call 
identification" feature. An incoming call is presented to the line. For conciseness of the diagram, line identification is 
not represented (which corresponds to the case of an internal waiting call). 
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PP2 

attached to line u 



PP1 

attached to line u 



FP 



Network 



Incoming call 
presentation 




Call established with call id 1 (external or internal) 



CC-SETUP 



« CALLING PARTY NUIVIBER, 

< Calling Party Address = 'calling number' > » 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = call id 2 > » 



Call waiting 
indication 



If PP2 accepts the call 
(or accepts it first) 



CC-INFO 




ncoming call from 
calling number' 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 



CC-CONNECT 



If PP1 accepts the (waiting) call 
(or accepts it first) 



CC-INFO 



« MULTI-KEYPAD, info = '1C 33'H » 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 



CC-INFO 



« MULTI-KEYPAD, info = '1C 35'H » 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 



CC-RELEASE 



CC-RELEASE-COM 



Figure C.I 4: Second incoming call on the line or system 

NOTE: When PPl does not implement "Call identification", the procedure used by the FP to release the call 
towards PPl when PP2 answers depends on the context: if PPl also tried to answer the call (and sent 
1C35H) but answered second, the FP uses the "call release and call release rejection" procedure 
(i.e. sends IC 33H, as here); if PPl did not answer at all, the FP uses the "On-hold call release" procedure 
instead (i.e. sends IC 37H). In both cases, a such PPl ignores the call id sent along with the message 
(call id 2) and only relies on the message itself. 
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C.3.3 First outgoing call on the line or system 

Use case: the PP is attached to a muhi-call line. An outgoing call is initiated. 



PP 

attached to 
a multiple-call line 'u' 



CC-SETUP 



CC-INFO 



« CALL-INFORIVIATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 



CC-INFO 



FP 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 



Use of line u 

for calling 

'called number' 



Network 




Figure C.15: First outgoing call on the line or system 

NOTE: Figure C.15 does not show the exchange of line identifiers. For a complete diagram, see for example 
clause C.2.2.2.1. 



£75/ 



161 



ETSI TS 102 527-3 VI. 1.1 (2008-06) 



C.3.4 Second outgoing call on the line or system 

Use case: the PPs are attached to a muhi-call line. A call is going on on PPl. A second external call is initiated. For 
conciseness of the diagram, line identification is not represented (which corresponds to the case of an internal outgoing 
call). 



PP2 

attached to line u 



PPl 

attached to line u 



FP 



Network 



Call established with call id 1 (external or internal) 



If second call is 
initiated by the PP2 



CC-SETUP 



CC-INFO 



« CALL-INFORIVIATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 

cc-i'nfo 



Use of line u (if 
external) for calling 
'called number' 




« MULTI-KEYPAD, < Keypad info = 'called number' > » 

« CALL-INFORIVIATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 



If second call is 
initiated by the PPl 



CC-INFO 



« IVIULTI-KEYPAD, < Keypad info = '15'H > » 
CC-INFO 



« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 

CC-INFO 



Use of line u (if 
external) for calling 
'called number' 




« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 



Figure C.16: Second outgoing call on the line or system 
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C.4 Parallel calls complex or alternative diagrams 

This annex illustrates use cases of the "Common parallel call procedures" feature (NG1.N.7) that are not described in 
the main part of the standard (see figures of clause 7.4.3.5) but require clarification, and gives guidelines for 
implementation. More specifically, it includes: 

• Alternative use cases. 

• Limit or complex use cases that may not happen so often but illustrate the philosophy of the standardized 
procedures. 

NOTE: Clauses C.2 and C.3 deal with "Multiple lines" and "Multiple calls" specific use cases (e.g. not applicable 
in the PSTN double call case). 

C.4.1 Call identification for outgoing parallel calls 

This clause shows variants of the "Outgoing parallel call initiation" diagrams presented in the procedure itself (see 
clause 7.4.3.5.1), that correspond to variant use cases. In all the diagrams presented, the call-id is sent by the FP as soon 
as possible, (and even if the line-id is not known at this stage) so that it can be used by the PP in all subsequent 
messages concerning that call (for messages that use the call id when available). 

C.4.1 .1 All in one PP message - line identification by PP 

Use case: The PP sends all parallel call initiation information in a single CC-INFO message (e.g. the user used the 
phone book before placing a parallel call). A single message sent by the PP with 15/17H + line-id + called-number; 



PP 




Ongoing call (external or internal) 




FP 



Outgoing call initiation including line selection by the PP (not FP-managed) 

CC-INFO 



Outgoing 

parallel call 

initiation 



OR 



Line selected by PP for the call 
using the CALL-INFO method 
(if external) 

Line selected by PP for the call 
lusing the KEYPAD method 
(if external) 



« MULTI-KEYPAD, < Keypad info = '15/17'H> » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 
value = 'u' > » 



I 



« MULTI-KEYPAD, 

< Keypad info = '23 3u'H > » 



« MULTI-KEYPAD, < Keypad info = 'called number' 



> » 



Call id assignement by the FP 



CC-INFO 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 
value = 'u' > 



Repeated here as a result of the 

CALL-INFO completion principle 

I 

Possibly ignored if PP does not implement < id type/subtype = 'Call identifier', 
the "Call identification" feature value = 'assigned call id' > 



Figure C.17: Outgoing parallel calls: all in one PP message, line identification by PP 
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C.4.1 .2 All in one PP message - FP-managed line selection 

Use case: The PP sends all parallel call initiation information in a single CC-INFO message (e.g. the user used the 
phone book before placing a parallel call). However, "FP-managed line selection" is used. A single message sent by the 
PP with 15/17H + called-number, but without line-id. 



PP 



FP 




Ongoing call (external or internal) 




Outgoing call initiation with FP-managed line selection 

Outgoing 

parallel call 

initiation 



CC-INFO 



« MULTI-KEYPAD, < Keypad info : 
< Keypad info ■■ 



'15/17'H> » 
'called number' > » 



Call id assignement and 
line selection by the FP 

Line selection performed 
by the FP 



possibly ignored if PP does not implement 
the "Call identification" feature 



CC-INFO 



« CALL-INFORIVIATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'u' > 

< id type/subtype = 'Call identifier', 

value = 'assigned call id' > 



Figure C.18: Outgoing parallel calls: all in one PP message, FP managed line selection 

C.4.1 .3 Line pre-selection by PP - Manual dialling of called number 

Use case: The PP sends initiates a parallel call with 15/17H + line-id in a single CC-INFO message (e.g. the user 
pre-selected or pre-dialled ('#k') the line to use-unless the PP is attached to only one line, in which case the user does 
not have to do so, but the present use case still applies-before manually dialling the called number). The FP replies with 
the call-id as soon as it received the first message, and before dialling of the called number. 
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PP 



FP 




Ongoing call (external or internal) 




Outgoing call initiation with Line selection by the PP (not FP-managed) 

CC-INFO 



Outgoing 

parallel call 

initiation 



OR 



Line selected by PP for the call 
using the CALL-INFO method 
(if external) 

Line selected by PP for the call 
using the KEYPAD method 
(if external) 



« MULTI-KEYPAD, < Keypad info = '15/17'H> » 

« CALL-INFORIVIATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'u' > » 

« IVIULTI-KEYPAD, 

< Keypad info = '23 3u'H > » 



Call id assignement by the FP 



CC-INFO 



Repeated here as a result of the 
CALL-INFO completion principle. 

possibly ignored if PP does not implement 
the "Call identification" feature 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call' 

value = 'u' > 

< id type/subtype = 'Call identifier', 

value = 'assigned call id' > 



CC-INFO 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 
« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'u' > 

< id type/subtype = 'Call identifier', 

value = 'assigned call id' > 



Figure C.19: Outgoing parallel calls: line pre-selection by PP, Manual dialling of called number 

C.4.1 .4 FP-managed line selection - Manual dialling of called number 

Use case: The PP initiates a parallel call with 15/17H (e.g. the user pressed the R/INT key before manually dialling the 
called number). The FP replies with the call-id as soon as it received the first message, and before dialling of the called 
number. When sending the call-id, the FP cannot send the line-id together with it (because FP does not know at this 
stage if PP will use FP-managed line selection). 

NOTE: This use case is listed here as a reminder, as it is already presented as a mainstream use case in the 
"Outgoing parallel call initiation" procedure (see clause 7.4.3.5.1, figure 5). 

C.4.1 .5 Unsupported new outgoing parallel call 

Use case: The PP initiated an outgoing parallel call (external or internal) at a point in time where the FP and/or the line 
cannot support the additional call. A "busy system or line notification" (see clause 7.4.8.3) is sent to the PP. If a call id 
was assigned to the new call (a call context was created on FP side and the call id was notified to the PP), a "call 
release" must be also sent. 
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PP 



FP 




Ongoing call (external or internal) 




Outgoing call initiation including line selection by the PP (not FP-managed) 

CC-INFO 



Outgoing 

parallel call 

initiation 



OR 



Line selected by PP for the call 
using the CALL-INFO method 
(if external) 

Line selected by PP for the call 
using the KEYPAD method 
(if external) 



« MULTI-KEYPAD, < Keypad info = '15/1 7'H > » 

« CALL-INFORIVIATION, 

< id type = 'Line identifier', subtype = 'external call', 
value = 'u' > » 

« IVIULTI-KEYPAD, 

< Keypad info = '23 3u'H > » 



« MULTI-KEYPAD, < Keypad info = 'called number' > » 



Busy system or line notification after 
call id assignment: call release needed 



Call id assignment 

CC-INFO 



Repeated here as a result of the 
CALL-INFO completion principle 

possibly ignored if PP does not implement 
the "Call identification" feature 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'u' > 

< id type/subtype = 'Call identifier', 

value = 'assigned call id' > 
» 

Busy system or line notification 

CC-INFO 



« SIGNAL value = 'busy tone' = '04'H » 

« CALL-INFORMATION ... same values as above. » 

Call release 

CC-INFO 



« MULTI-KEYPAD, info = '1C 33'H » 

« CALL-INFORMATION ... same values as above. » 



Busy system or line notification 
before call id assignment (i.e. before 
call context was created 



Busy system or line notification 

CC-INFO 



« SIGNAL value = 'busy tone' = '04'H » 



« CALL-INFORMATION, 
Selected line-id shall be present < id type = 'Line identifier', subtype = 'external call'. 

Call-id is absent since it was not assigned value = 'u' > 



Figure C.20: Outgoing parallel calls: unsupported new outgoing parallel call 
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C.4.2 Incoming parallel calls 

C.4.2.1 Two simultaneous incoming calls on two different lines 

Use case: the PP is attached to several lines. An incoming call is received on two different lines. This use case shows 
that from the PP point of view, this use case does not fundamentally differ from the use case where two simultaneous 
calls occur on a single line. 



PP 

attached at least to 
two lines u and v 



FP 



Network 



CC-SETUP 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number 1' > » 
« CALL-INFORMATION, 



< Identi 

< Identi 

< Identi 

< Identi 

< Identi 

< Identi 



tier type = 'Line identifier' > 

tier subtype = 'Line identifier for external calls' >i 

fier value = u > » 

fier type = 'Call identifier' > 

fier subtype = 'Call identifier' > 

fier value = 'call-id 1' > 

CC-INFO 




Incoming call to line u 
from 'calling number 1' 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number 2' > » 
« CALL-INFORMATION, 

< Identifier type = 'Line identifier' > 

< Identifier subtype = 'Line identifier for external calls' > 

< Identifier value = V > » 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call-id 2' > 




Incoming call to line v 
from 'calling number 2' 



Figure C.21 : Incoming parallel calls: two simultaneous incoming calls on two different lines 
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C.4.2.2 FP release of waiting call when remote party hangs up 

Use case: use of call release from the FP when the remote partie hangs up. This may occur even before the PP answered 
the call. 



PP2 

attached to line u 



FP 



Network 



CW tone 
heared by user 



Line on which waiting call 
occurred if external 



CW context 
created 



CW context 
deleted 



Call established with call id 1 (external or internal) 



CC-INFO 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« SIGNAL value = 'call waiting tone' = '07'H » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type/subtype = 'Call identifier, 

value = 'waiting call id' = call Id 2 > 



Call release used for a waiting call 

CC-INFO 



« MULTI-KEYPAD, info = '1C 33'H » 
« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type/subtype = 'Call identifier', 

value = 'call id 2' > 



remote party 
hangs up 



Call established with call id 1 continues 



Figure C.22: Incoming parallel calls: FP release of waiting call when remote party hangs up 

C.4.2.3 Two incoming calls before user answers 

Use case: Two calls are arriving before the user anwsers any of them. Both calls are presented to the user on the MMI 
and the user selects one of them. Use of CC-CONNECT (with no identified call) automatically means that the first call 
(presented with CC-SETUP) is picked up. If the user selects the second call, the PP must send a call waiting acceptation 
before the CC-CONNECT is sent to the FP. 
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PP1 

attached to lines u and v 
V possibly equal to u 



FP 



Network 



Line on which waiting call 
occurred if external 



CW tone 
heared by user 



Line on which waiting call 
occurred if external 



Both calls presented to 
PP1 through MMI 



If call with call-id 1 is 
accepted bv the user 



If call with call-id 2 is 
accepted bv the user 



CC-SETUP 



« CALL-INFORIVIATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'u' > 

< id type/subtype = 'Call identifier', 

value = 'waiting call id' = call id 1 > 



CC-INFO 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« SIGNAL value = 'call waiting tone' = '07'H » 
« CALL-INFORIVIATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'v' > 

< id type/subtype = 'Call identifier', 

value = 'waiting call id' = call id 2 > 



CC-CONNECT 



CC-INFO 



« IVIULTI-KEYPAD, info = '1C 35'H » 
« CALL-INFORIVIATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'v' > 

< id type/subtype = 'Call identifier', 

value = 'call-id2' > 
» 

CC-CONNECT 



CC-CONNECT-ACK 



First incoming 
call (call id 1) 



Call waiting 
indication 
(call-id 2) 



Call with call id 2 established 



Figure C.23: Incoming parallel calls: Two incoming calls before user answers 

C.4.3 Call waiting represented as first call when user hangs up 

Use case: the PP is attached to a muhi-call line. A call is on going from PPL A second incoming call is presented to the 
line. The PP hangs up and the call is represented as a first incoming call. 
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PP 

attached to 
multiple-call line u 



FP 



Network 



Call waiting 
indication 



User 
hangs up 



Incoming call 
presentation 



Call established with call id 1 (exterral or internal) 



CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 



CC-RELEASE 



CC-RELEASE-COM 



CC-SETUP 




Incoming call from 
'calling number' 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call id 2' > » 



NOTE; The «CALL-INFORMATION» information element is not sent in a CC-RELEASE or CC-RELEASE-COM 
message. 

Figure C.24: Call waiting represented as first call when user hangs up 



C.5 List access service use case examples 
C.5.1 General 

In the following clauses, several use case examples for list access are depicted. 

It has to be noted that the sequences are only examples, it cannot be mandatory that the message flows shall always be 
exactly in the described way. However it is recommended to follow the examples where possible in order to ensure 
interoperability. 

For clarity of the following flowcharts, «Call information» IE including call identifiers and line identifiers does not 
appear in some of the CC messages that must convey it. Please note that they should not be omitted when implementing 
equivalent cases. 



£75/ 



170 



ETSI TS 102 527-3 VI. 1.1 (2008-06) 



C.5.2 Use case: transfer number from missed call list to contact 
list 



PT 



FT 



user starts missed call list 



CC-Setup 



IE « BASIC_SERVICE < Call Class=Normal call setup > » 
CC-Call-Proc 



IWU-lnfo 



IE « IWU to IWU= start session , missed call list, Nb sorting field 
identifiers=0 » 



IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier=1 , Total number, 
Sorting field identifier 1=date and time » 



IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 

IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part i » 



user selects entry to save in contact list 



IWU-lnfo 



IE « IWU to IWU= start session, contact list, Nb sorting field identifiers=0 » 



IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier=2. Total number. Sorting 
field identifier1=name, Sortina field identifier2=First name » 



Figure C.25: List access use case: transfer number from missed call list to contact list (1/2) 
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PT 


IWU-lnfo 


FT 
























IE « IWU to IWU= save entry, session id=2, entry identifier=OOH » 










IWU-lnfo 




















IE « IWU to IWU= data packet, session id=2, content part 1 » 










IWU-lnfo 










IE « IWU to IWU= data packet last, session id=2, content part j » 










IWU-lnfo 










E « IWU to IWU= save entry confirm, session id=2, position index, entry 

identifier =xxH » 

IWU-lnfo 




















IE « IWU to IWU= end session, session identifier=1 » 










IWU-lnfo 










IE « IWU to IWU= end session confirm, session identifier=1 » 

IWU-lnfo 










IE « IWU to IWU= end session, session identifier=2 » 








^ 


IWU-lnfo 










IE « IWU to IWU= end session confirm, session identifier=2 » 
CC-RELEASE 










CC-RELEASE-COM 

















Figure C.26: List access use case: transfer number from missed call list to contact list (2/2) 

The second session might also be established after release of the first session. FP shall be capable to handle at least two 
sessions independently. 
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C.5.3 Use case: select and call internal party 



PT 



FT 



Direct PT initiated linl< establishment 



CC-Setup 



IE « BASIC_SERVICE <Call Class=lnternal call setup> » 
CC-Call-Proc 



IWU-lnfo 



IE « IWU to IWU= start session, internal names list, Sorting field 
identifierl =number » 

IWU-lnfo 



IE « IWU to IWU= start session confirm, session identifier. Total number. 
Sorting field identifierl =number » 

IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 

IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 





ivvu-inro 






IE « IWU to IWU= data packet last, session id, content part m » 






IWU-lnfo 


► 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 



CC-lnfo 



IE « MULTI-KEYPAD, int-key -i- number digits » 



Figure C.27: List access use case: select and call internal party 

The int-key is necessary at least in case basic service is not internal call. 



£75/ 



173 



ETSI TS 102 527-3 VI. 1.1 (2008-06) 



C.5.4 Use case: select and call number from contact list 



PTs 



FT 



Direct PT initiated link establishment 



CC-Setup 



IE « BASIC_SERVICE < Call Class=Normal call setup > » 
CC-Call-Proc 



IWU-lnfo 



IE « IWU to IWU= start session, contact list, Nb sorting field identifier=0 » 



IWU-lnfo 



E « IWU to IWU= start session confirm, session identifier. Total number. Sorting 
field identifier1=name Sorting field identifier2= first name » 

IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 

IWU-lnfo 



IE « IWU to IWU= read entries confirm, session id, counter » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m » 

IWU-lnfo 



IE « IWU to IWU= end session, session identifier » 



IWU-lnfo 



IE « IWU to IWU= end session confirm, session identifier » 



CC-lnfo 



IE « MULTI-KEYPAD, number digits » 



Figure C.28: List access use case: select and call number from contact list 
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C.5.5 Use case: save entry with invalid format 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= save entry, session id, entry identifier » 



IWU-lnfo 



IE « IWU to IWU= data packet, session id, content part 1 (invalid entry format) » 



IWU-lnfo 



IE « IWU to IWU= data packet last, session id, content part m (invalid entry 

format) » 



IWU-lnfo 



IE « IWU to IWU= negative acknowledgement, session id, reject reason=entry 

format incorrect » 



Figure C.29: List access use case: save entry with invalid format 



C.5.6 Use case: read invalid start index 



PT 



FT 



list access session setup 



IWU-lnfo 



IE « IWU to IWU= read entries, session id, start index, counter, list of field 

identifiers » 



IWU-lnfo 



IE « IWU to IWU= negative acknowledgement, session id, reject 
reason=invalid start index » 



Figure C.30: List access use case: read invalid start index 
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C.5.7 Use case: modify a PP internal name 

The user edits the internal name of the PP number '3' in the DECT system. This use case can be used just after 
subscription registration or later. 



PP 



FP 



Internal names list access start session 



IWU-INFO 



IE « IWU to IWU=search entries, session id, matching option=OOH, 
searched value = 33H, counter=1 , list of field identi fiers= Number id, Name id » 



IWU-INFO 



IE « IWU to IWU=search entries confirm, session id, start index, counter=1 » 



IWU-INFO 



IE « IWU to IWU=data paclcet last, session id, content part=(entry 
identifier, number, name) for 3'''^ entry » 

IWU-INFO 



IE « IWU to IWU=edit entry, session id, entry identifier, list of field 
identifiers^ number id, name id » 



IWU-INFO 



IE « IWU to IWU=edit entry confirm, session id, start index » 
IWU-INFO 



IE « WU to IWU=data paclcet last, session id, content part= ontent part= 
(entry identifier, number, name) for 3'^'' entry » 



user updates the 'name' field for 3'"'' entry in internal name list 



IWU-INFO 



IE « IWU to IWU=save entry, session id, entry identifier » 
IWU-INFO 



IE « IWU to IWU=data paclcet last, session id, content part = 3 
entry content updated » 

IWU-INFO 



IE « IWU to IWU=save entry confirm, session id, entry identifier, start index » 



Internal names list access end session 



FP notifies PP 3 of the changing of its name using clause 7.4.1 0.2 



Figure C.31 : List access use case: modify a PP internal name 
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C.6 List access service with voice calls (additional use 
cases and procedure diagrams) 

C.6.1 General 

In the following clauses, several procedure diagrams for list access service combined with voice calls are depicted. 

It has to be noted that the sequences are only examples, it cannot be mandatory that the message flows shall always be 
exactly in the described way. However it is recommended to follow the examples where possible in order to ensure 
interoperability. 

C.6. 2 List access when a voice call is already ongoing 

Please note that for clarity of the flowcharts, the line identifier is not mentioned. However it has to be implemented and 
managed correctly as defined by the present document. 

C.6. 2.1 Use case: Consult a list during a voice call 

Use case: Look for the number of a contact while you are in voice call and then come back to the voice call. 

PP FP 




Ongoing call 1 (external or internal) with call-id 1 



Put call 1 on hold (mandatory only if Cf channel used for list access, optional otherwise) 




CC-INFO 



« MULTI-KEYPAD, info = '1 C 41 'H » 

« CALL-INFORIVIATION, Line Id, 'call-id 1' > 



Access contact list (within call 1) 



IWU-INFO 



« IWU-TO-IWU <Command = start sesslon>, <List identifier = contact list> » 



IWU-INFO 



« IWU-TO-IWU <Command = end session confirm>, <session identifier> » 



Resume call 1 (mandatory only if Cf channel used for list access, optional otherwise) 



CC-INFO 



« MULTI-KEYPAD, info = '1 C 42'H » 

« CALL-INFORMATION, Line Id, 'call-id 1' > 




Back to ongoing call 1 (external or internal) 




Figure C.32: List access use case: consult a list during a voice call 
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C.6.2.2 Use case: call transfer using internal names list (first call explicitly 
put on hold) 

Use case: Ongoing call is put on hold before establishing a parallel internal call using the internal names list. The first 
call is then transferred. It shows in particular that a call can optional be put on hold before an outgoing second call is 
made. In this case, it is proposed that an additional call id is attached to the list access. 



NOTE: The list access re-uses call idl. 
PP 



FP 




Ongoing call 1 (external or internal) with call-id 1 




Put call 1 on hold 

CC-INFO 



« IVIULTI-KEYPAD, info = '1C 41'H » 

« CALL-INFORIVIATION, Line Id, 'call-id 1' > 



Access internal names list to find call transfer target (within call 1) 



IWU-INFO 



« IWU-TO-IWU <Command = start session>, <List identifier = internal names list> » 



IWU-INFO 



« IWU-TO-IWU <Command = end session confirm>, <session identifier> » 



Establish parallel internal call 2 



CC-INFO 



« MULTI-KEYPAD, 17H + terminal id number » 

CC-INFO Call id assignment by the 



« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = 'call id 2' > » 



Call transfer request 



CC-INFO 



Only if the PP 

implements 

the "Call 

identification" feature 



« MULTI-KEYPAD, info = '1C 34'H » 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 



Figure C.33: List access use case: call transfer using internal names list 
(first call explicitly put on hold) 

C.6.2.3 Use case: call transfer using internal names list (first call implicitly 
put on hold by internal call) 

Use case: Ongoing call is implicitly put on hold before establishing a parallel internal call using the internal names list. 
The first call is then transferred. It shows in particular that the 17H implicitly puts the ongoing call on hold. 

NOTE: The list access re-uses call id2. 
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PP 



FP 




Ongoing call (external or internal) with call-id 1 




Request internal call, call 1 implicitely put on hold 



CC-INFO 



« MULTI-KEYPAD, 17H » 
« CALL-INFORMATION, Line Id, 'call-id 1' > 

CC-INFO Call id assignement by the 



« CALL-INFORMATION, < Id type/subtype = 'Call identifier', value = call id2 > » 



Access internal names list to find call transfer target (within call id 2) 



IWU-INFO 



IWU-TO-IWU <Command = start session>, <List identifier = internal names list> 

IWU-INFO 
« IWU-TO-IWU <Command = end session confirm>, <session identifier> » 



Establish parallel internal call 2 



CC-INFO 



« MULTI-KEYPAD, Called nb = terminal id number » 
CC-INFO 



« CALL-INFORMATION, < id type/subtype = 'Call identifier', value = call id2 > » 



Call transfer request 



CC-INFO 



Only if the PP 

implements 

the "Call 

identification" feature 



« MULTI-KEYPAD, info = '1C 34'H » 
« CALL-INFORMATION, 

< Identifier type = 'Call identifier' > 

< Identifier subtype = 'Call identifier' > 

< Identifier value = 'call-id 1' > 



Figure C.34: List access use case: call transfer using internal names list 
(first call explicitly put on hold) 
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C.6.2.4 Use case: establishing a parallel call using contact list 

Use case: During an ongoing call, the user establishes a parallel external call using the contact list. In this case, there is 
no need for an additional call id for the list access: it is done within existing call. 



PP 



FP 




Ongoing call (external or internal) on call id1 




Put call 1 on hold 

CC-INFO 



« MULTI-KEYPAD, info = '1C 41'H » 

« CALL-INFORMATION, Line Id, 'call-id 1' > 



Access contact list to find a contact (within call id 1) 



IWU-INFO 



« IWU-TO-IWU <Command = start session>, <List identifier ^contact list> » 

IWU-INFO 
« IWU-TO-IWU <Command = end session confirm>, <session identifier> » 



Try to establish parallel external call 2 

CC-INFO 



« MULTI-KEYPAD, 15H + external number » 
CC-INFO 




« CALL-INFORMATION, Line Id, 'call id 2' > » 



Parallel external call establish on call id2 




Figure C.35: List access use case: establishing a parallel call using contact list 

C.6.3 Incoming voice call during list access session 

Please note that for clarity of the flowcharts, the line identifier is not mentioned. However it has to be implemented and 
managed correctly as defined by the current standard. 

C.6.3. 1 Use case: incoming voice call during list access, previous 
connection released 

Use case: A list access call is on going from a PP. An incoming call is presented to the line. The FP hangs up the list 
access call before presenting the incoming call. 
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PP 



Incoming call 
presentation 



List access call established (call id 1 ) 



List access end session 



CC-RELEASE 



CC-RELEASE-COM 



CC-SETUP 



FP 



Network 



« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 
« CALL-INFORMATION, Lineld, call id 1» 




Incoming call from 
'calling number' 



FP 
hangs up 

FP presents incoming call 
uses call id1 which is free 



Figure C.36: List access use case: incoming voice call during list access, 
previous connection released 

NOTE: The first list access may have or not a call id assigned by the FP. Depending mainly on the service type 
used to setup the list access call. 

C.6.3.2 Use case: incoming call during list access, managed as a parallel 
call, previous session ended 

Use case: A list access call is on going from a PP. An incoming call is presented to the line. The FP closes the list 
access session before presenting the incoming call. 



PP 



Incoming call 
presentation 



FP 



List access call established (call id 1) 



List access end session 



CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 
« CALL-INFORMATION, Lineld, call id 2» 



Network 




Incoming call from 
'calling number' 



Figure C.37: List access use case: incoming voice call during list access, 
previous connection released 

NOTE: The first list access may have or not a call id assigned by the FP. Depending mainly on the service type 
used to setup the list access call. 
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C.6.3.3 Use case: incoming voice call during list access, managed as 
parallel call, previous session not ended 

Use case: A list access call is on going from a PP. An incoming call is presented to the line. The FP manages it as a 
parallel call. 

NOTE: The first list access may have or not a call id assigned by the FP. Depending mainly on the service type 
used to setup the list access call. 



PP 



Incoming call 
presentation 



FP 



List access call established with call-id 1 



CC-INFO 



« SIGNAL value = 'call waiting tone' = '07'H » 
« CALLING PARTY NUMBER, 

< Galling Party Address = 'calling number' > » 
« CALL-INFORMATION, Lineld, call id 2 » 



Network 




Incoming call from 
'calling number' 



Figure C.38: List access use case: incoming voice call during list access, 
managed as parallel call, previous session not ended 



C.7 DECT system settings diagrams 
C.7.1 General 

In the following flowcharts, we assume that: 

• N lines are defined, i.e. 'Total number of entries' = N in line settings list before starting lines settings session. 

• The total number of registered PPs is M, i.e. 'Total number of entries' = M in internal names list before starting 
internal names session. 

• Only one data packet command is necessary to read one entry content, i.e. 'data packet last' command is 
received directly. 

NOTE: In the following flowcharts, the read entries or search entries might be done prior to the sequence (in a 
previous session for example). But this is not the most usual behaviour as the PP may probably show the 
current value of the setting before enabling the user to modify it. 

For clarity of the following flowcharts the «Call information» IE including call identifier does not appear in the CC 
messages that must convey it. Please note that it should not be omitted when implementing equivalent cases. For 
example the call identifier must be assigned by the FP after CC-SETUP message. 

C.7.2 Modifying the PIN code 

Use case: FP without keyboard, the user modifies the system PIN code from the PP. 
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PP 



FP 



Enter old PIN code 



IE 



r 



CC-SETUP 



« BASIC SERVICE <Call Class=Service call setUD> » 
CC-CALL-PROC 



IWU-INFO 



«IWU to IWU= start session, DECT system settings list, Number of sorting fields 

CIPHER-REQUEST 



:0» 



Encrypted 



IWU-INFO 



IE «IWU to IWU= start session confirm, session identifier. Total number=1 >; 



Read old PIN c ode 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =1 , counter=01 H, 
list of field identifiers= FP registration mode, PIN code, ..., FP version » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1 » 

IWU-INFO 



IE «IWU to IWU= data packet, session id, content part » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part » 



If entered PIN 



code matches FP return PIN 



IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= PIN code » 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= (entry identifier, 

PIN code) > 



New PIN code is entered twice. If equal, PP saves the new PIN code value 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



IE «IWU to IWU= data packet last, session Id, content part = updated PIN code>[> 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, start index» 



DECT system settings end session 



Figure C.39: Modifying the PIN code 
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C.7.3 Resetting the base 

Use case: Reset all DECT system and line settings to their default value. 



PP 



FP 



DECT system settings start session 



Read DECT 



iystem settings: 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =1 , counter=01 H, 
list of field identifiers= FP registration mode, PIN code, ..., FP version » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data packet, session id, content part » 
IWU-INFO 



IE «IWU to IWU= data pacl<et last, session id, content part » 



IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= Base reset » 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= (entry identifier. 

Base reset) > 



User confirms system and line settings reset 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = (Base reset, YES) >\> 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, start index» 



DECT system settings end session 



Figure C.40: Reseting the base 
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C.8 Line settings diagrams 
C.8.1 General 

In the following flowcharts, we assume that: 

• N lines are defined, i.e. 'Total number of entries' = N in the line settings list before starting lines settings 
session. 

• Only one data packet command is necessary to read one entry content, i.e. 'data packet last' command received 
directly. 

In the following flowcharts, the read entries or search entries might be done prior to the sequence (in a previous session 
for example). But this is not the most usual behaviour as the PP may probably show the current value of the setting 
before enabling the user to modify it. 

For clarity of the following flowcharts the «Call information» IE including call identifier does not appear in the CC 
messages that must convey it. Please note that it should not be omitted when implementing equivalent cases. For 
example the call identifier must be assigned by the FP after CC-SETUP message. 

C.8. 2 Changing the settings of a line 

Use case 1: The user edit the line settings of the line number 'i'. Read only the selected entry. 
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PP 



FP 



Line i selected 



IE 



CC-SETUP 



« BASIC_SERVICE <Call Class=Service call setup> » 
CC-CALL-PROC 



IWU-INFO 



IE «IWU to IWU= Start session, lines settings, Number of sorting fields =0 » 

IWU-INFO 
IE «IWU to IWU= start session confirm, session identifier, total number=N » 



by the user(i el.. N): 



IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =i, counter=01 H, 
list of field identifiers= Line id id. Line name id, ..., IVIultiple calls mode id » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=1» 

IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part for i entry» 

IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= Line id id. Line name id, ..., IVIultiple calls mode id» 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 
IWU-INFO 



«IWU to IWU= data packet last, session id, content part= content part for i entry 



user updates the settings for i line in line settings list 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= i'" entry 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, start index» 

IWU-lnfo 



IE «IWU to IWU= end session, session identifier» 
IWU-lnfo 



IE «IWU to IWU= end session confirm, session identifier » 

FACILITY 



«EVENTS NOTIFICATIONS, <List change indication. Line settings, 
N> > « CALL-INFORMATION, Lineld » 

CC-RELEASE 



CC-RELEASE-COIVI 



FP notifies all PP 
attached to the line 



Figure C.41 : Changing the settings of a line (use case 1) 

Use case 2: The user edit the line settings of the line number 'i'. Read all N entries before editing the selected entry. 
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PP 



FP 



IE 



CC-SETUP 



« BASIC_SERVICE <Call Class=Service call setup> » 
CC-CALL-PROC 



IWU-INFO 



IE «IWU to IWU= Start session, lines settings, Number of sorting fields =0 » 

IWU-INFO 



IE «IWU to IWU= start session confirm, session identifier, total number=N » 

IWU-INFO 



IE «IWU to IWU= read entries, session id, start index =1, counter=N, 
list of field identifiers= Line id id. Line name id, ..., Multiple calls mode id » 

IWU-INFO 



IE «IWU to IWU= read entries confirm, session id, start index, counter=N» 

IWU-INFO 



IE «IWU to IWU= data pacl<et, session id, content part » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part » 



Line i selectee by the user (i € 1.. N): 



IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, 
list of field identifiers= Line id id. Line name id, ..., Multiple calls mode id» 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 
IWU-INFO 



«IWU to IWU= data packet last, session id, content part= content part for i entry 



user updates the settings for i line in line settings list 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier » 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part= i'" entry 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, start index» 

IWU-lnfo 



IE «IWU to IWU= end session, session identifier» 
IWU-lnfo 



IE «IWU to IWU= end session confirm, session identifier » 

FACILITY 



«EVENTS NOTIFICATIONS, <List change indication. Line settings, N> > 

« CALL-INFORMATION, Lineld » 

CC-RELEASE 



CC-RELEASE-COM 



FP notifies all PP 
attached to the line 



Figure C.42: Changing the settings of a line (use case 2) 
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C.8.3 Changing the name of a line 

Use case: The user edit directly the line name of the line number '3'. 



£75/ 



188 



ETSI TS 102 527-3 VI. 1.1 (2008-06) 



PP 



FP 



CC-SETUP 



«Basic Service=xxH» 
CC-CALL-PROC 



IWU-INFO 



IE «IWU to IWU= Start session, lines settings list, Number of sorting fields =0» 

IWU-INFO 



IE «IWU to IWU= start session confirm, session identifier. Total number=N 

IWU^fKlFO 



IE «IWU to IWU= search entries, session id, matching options= OOH, 
search string = '33H', counter=1 , list of field identifiers= Line Id id, Line name id 

IWU-INFO 



IE «1WU to IWU= search entries confirm, session id, start index, 

IWU-INFO 



IE «IWU to IWU= data pacl<et last, session id, content part= (entry identifier, 
line Id, Line name) for 'line 3' » 

IWU-INFO 



IE «IWU to IWU= edit entry, session id, entry identifier, list of field identifiers^ 

Line Id id. Line name id » 

IWU-INFO 



IE «IWU to IWU= edit entry confirm, session id, start index » 

IWU-INFO 



IE «IWU to IWU= data pacl<et last, session id, content part= content part= 
(entry identifier, line Id, Line name) for 'line 3' » 



user updates the 'Line name' field for 'line 3' entry in line settings list 



IWU-INFO 



IE «IWU to IWU= save entry, session id, entry identifier» 
IWU-INFO 



IE «IWU to IWU= data packet last, session id, content part = 'line 3' content 

IWU-INFO 



IE «IWU to IWU= save entry confirm, session id, entry identifier, start index» 

IWU-lnfo 



IE «IWU to IWU= end session, session identifier» 
IWU-lnfo 



IE «IWU to IWU= end session confirm, session identifier » 

FACILITY 



FP notifies all PP 
attached to the line 



«EVENTS NOTIFICATIONS, <List change indication. Line settings, 
N> > « CALL-INFORMATION, Lineld » 

CC-RELEASE 



CC-RELEASE-COM 



Figure C.43: Changing the name of a line 
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Annex D (informative): 

Services and features defined in other specifications 

D.1 Services and features defined in TS 102 527-1 (New 
Generation DECT; part 1) 

The following informative annex shows the features and MAC/DLC services defined in TS 102 527-1 [21] (New 
Generation DECT; part 1), many of them are reused in the present document. This list is informative, and shows the 
status in TS 102 527-1 [21] (VI. 2.1). In case of changes or divergences the original definitions at TS 102 527-1 [21] 
shall rule. 

D.I .1 New Generation DECT; part 1 , Speech Services (clause 5.1 
ofTS 102 527-1) 

Narrow band ADPCM G.726 voice service [NGl.l]: ITU-T Recommendation G.726 [15] narrow band codec 
[NGl.SC.l] over 32 kbit/s unprotected transmission channel. 

Narrow band PCM G.711 voice service [NG1.2]: ITU-T Recommendation G.71 1 [16] narrow band codec 
[NG1.SC.2] over 64 kbit/s protected or unprotected transmission channels. 

Wideband 7 kHz G.722 voice service [NG1.3]: ITU-T Recommendation G.722 [17] wideband codec [NG1.SC.3] 
over 64 kbit/s protected or unprotected transmission channels. 

Wideband 7 kHz low rate G.729.1 voice service [NG1.4]: ITU-T Recommendation G.729.1 [18] wideband codec 
[NG1.SC.4] over 32 kbit/s unprotected transmission channels. 

Super wideband 14 kHz MPEG-4 ER AAC-LD voice service [NG1.5]: MPEG-4 ER AAC-LD super wideband 
codec [NG1.SC.5] over 64 kbit/s protected or unprotected transmission channels. 

Wideband 11 kHz low rate MPEG-4 ER AAC-LD voice service [NG1.6]: MPEG-4 ER AAC-LD super wideband 
codec [NG1.SC.6] over 32 kbit/s unprotected transmission channels. 

D.I .2 New Generation DECT; part 1 , Network (NWK) features 
(clause 5.2 of TS 102 527-1) 

Codec Negotiation [NGl.N.l): capability to negotiate the speech codec to be used in a communication, based on the 
supported capabilities in both peers and the previsions included in the present document. This feature may require slot 
type change. 

Codec Switching [NG1.N.2): capability to switch between different speech codecs during a call. This feature may 
require slot type change. 

D.I .3 New Generation DECT; part 1 , Data Link Control (DLC) 
services (clause 5.3 of TS 102 527-1) 

LUl Transparent Unprotected service (TRUP) Class 0/minimum_delay [NGl.D.l]: transparent unprotected 

service introducing minimum delay , transmission Class 0/min_delay as defined by EN 300 175-4 [4], clause 1 1.2. 

LUl Transparent Unprotected service (TRUP) Class [NG1.D.2]: transparent unprotected service introducing 

minimum delay , transmission Class as defined by EN 300 175-4 [4], clause 1 1.2. 

LU7 64 kbit/s protected bearer service [NG1.D.3]: protected service providing reliable 64 kbit/s transmission over 
packet type P80 incorporating EEC and ARQ protection mechanisms. Defined by EN 300 175-4 [4], clause 11.9. 
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LU12 UNProtected Framed service (UNF) Class [NG1.D4]: unprotected service introducing normal delay , 

transmission Class as defined by EN 300 175-4 [4], clause 11. 14. 

FUl DLC frame [NG1.D.5]: bidirectional frame used in LUl service. Defined in EN 300 175-4 [4], clause 12.2. 
Frame length depends on slot type and is defined in table 12.2.1.1 of EN 300 175-4 [4], clause 12.2.1. 

FU7 DLC frame [NG1.D.6]: bidirectional frame used in LU7 service. Defined in EN 300 175-4 [4], clause 1 1.9. 

FU12 DLC frame with adaptation for codec G.729.1 [NG1.D.7]: bidirectional frame used in LU12 service, as 
defined in EN 300 175-4 [4], clause 12.12, frame size specified for full slot, 2-level modulation and with the adaptation 
for codec G.729.1 defined in EN 300 175-4 [4], clause E.l. 

D.1 .4 New Generation DECT; part 1 , Medium Access Control 
(IVIAC) services (clause 5.4 of TS 102 527-1) 

lN_minimum delay symmetric MAC service type [NGl.M.l]: lN_minimum delay symmetric connection as defined 

in EN 300 175-3 [3], clause 5.6.2.1. 

lN_normal delay symmetric MAC service type [NG1.M.2]: lN_normal delay symmetric connection as defined in 

EN 300 175-3 [3], clause 5.6.2.1. 

IpQ_error_detection symmetric MAC service type [NG1.M.3]: Ipq_ error_detection symmetric connection as defined 
in EN 300 175-3 [3], clause 5.6.2.1. (type 3: Ip_ error_detection with single-subfield protected B-field as defined in 
EN 300 175-3 [3], clause 6.2.1.3.4). 

Advanced Connections [NG1.M.4]: MAC Connection Oriented service providing connection between FT and PT. 
Advanced connections are able to support multiple bearers, bearers different of the full slot, and any MAC service. The 
service includes the means for setting-up and releasing the required bearer(s). 

D.I .5 New Generation DECT; part 1 , Physical Layer (PHL) 
services (clause 5.5 of TS 102 527-1) 

2 level GFSK modulation [NGl.P.l]: 2 level Gaussian frequency Shift Key (GFSK) modulation as defined by 
EN 300 175-2 [2], clause 5. 

Physical Packet P32 [NG1.P.2]: physical packet P32 (full slot) as defined by EN 300 175-2 [2], clause 4.4.2. 

Physical Packet P64 [NG1.P.3]: variable capacity Physical packet POOj as defined by EN 300 175-2 [2], clause 4.4.3, 
withj =640. 

Physical Packet P67 [NG1.P.4]: variable capacity Physical packet POOj as defined by EN 300 175-2 [2], clause 4.4.3, 
with j = 672. 

Physical Packet P80 [NG1.P.5]: physical packet P80 (double slot) as defined by EN 300 175-2 [2], clause 4.4.4. 

D.I .6 New Generation DECT; part 1 , Speech coding and audio 
features (clause 5.6 of TS 102 527-1) 

G.726 32 kbit/s ADPCM [NGl.SC.l]: ITU-T Recommendation G.726 [15] narrow band codec as defined by 

EN 300 175-8 [8], clause 5.1. ITU-T Recommendation G.726 [15] codec is mandatory for New Generation DECT in 

order to ensure interoperability with existing DECT systems. 

G.711 64 kbit/s log-PCM [NG1.SC.2]: ITU-T Recommendation G.71 1 narrow band codec [16] as defined by 
EN 300 175-8 [8], clause 5.2. ITU-T Recommendation G.71 1 [16] codec is optional for New Generation DECT in order 
to improve the quality of narrow band communications, and fax/modem transmissions. ITU-T Recommendation 
G.71 1 [16] provides a slightly higher intrinsic voice quality and no transcoding for PSTN calls. Both, A-Law and 
)J,-Law are supported. 
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G.722 64 kbit/s wideband [NG1.SC.3]: ITU-T Recommendation G.722 wideband SB-ADPCM 7 kHz codec [17] as 
defined by EN 300 175-8 [8], clause 5.3. ITU-T Recommendation G.722 [17] is chosen as mandatory wideband codec 
for New Generation DECT in order to greatly increase the voice quality by extending the bandwidth from narrow band 
to wideband. ITU-T Recommendation G.722 [17] provides a high wideband quality at a bit rate of 64 kbit/s with low 
complexity and very low delay. 

G.729.1 32 kbit/s wideband [NG1.SC.4]: ITU-T Recommendation G.729.1 wideband codec [18] as defined by 

EN 300 175-8 [8], clause 5.4. ITU-T Recommendation G.729.1 [18] codec is optional for New Generation DECT in 

order to provide even higher wideband quality and better robustness to packets/frames losses than 

ITU-T Recommendation G.722 [17] at half the bit rate of ITU-T Recommendation G.722 [17]. This allows a better 

transport efficiency on the network side and over the DECT air interface (one full slot). In addition, it is seamless 

interoperable with largely deployed ITU-T Recommendation G.729 [i.6] based VoIP networks and terminals. 

ITU-T Recommendation G.729.1 [18] encodes signals in frames of 20 ms. It is a scalable codec operating at bitrates of 

8 kbit/s and from 12 kbit/s to 32 kbit/s per steps of 2 kbit/s, in narrow band or in wideband from 14 kbit/s. 

ITU-T Recommendation G.729.1 [18] already incorporates a high efficiency packet loss concealment mechanism. 

MPEG-4 ER AAC-LD 64 kbit/s super wideband [NG1.SC.5]: MPEG-4 ER AAC-LD codec [19], [20] as defined by 
EN 300 175-8 [8] clause 5.5.1. MPEG-4 ER AAC-LD is optional for New Generation DECT in order to provide higher 
quality than G.722 by further extending the bandwidth to superwideband (50 Hz to 14 kHz) (and even further, up to full 
audio bandwidth (20 Hz to 20 kHz)). MPEG-4 ER AAC-LD is designed for high quality communication applications 
including all kind of audio signals e.g. speech and music and provides a high quality for music streaming or other 
multimedia applications mixing speech and music. It provides an audio bandwidth of 14 kHz or more at a bitrate of 
64 kbit/s. MPEG 4 ER AAC-LD (Error resilient. Low Delay AAC profile) is standardized as an audio profile [19] of 
MPEG-4 (ISO/lEC 14496-3 [20]). The frame size is 10 ms and the algorithmic delay 20 ms. 

MPEG-4 ER AAC-LD 32 kbit/s wideband [NG1.SC.6]: as [NG1.SC5], but using the 32 kbit/s mode, as defined by 
EN 300 175-8 [8], clause 5.5.2. It provides a bandwidth of 1 1,5 kHz or more. The frame size is 20 ms and the 
algorithmic delay 40 ms. 

PLC (Packet Loss Concealment) G.722 Appendix III & IV [NG1.SC.7]: to better cope with transmission errors, a 
Packet Loss Concealment algorithm (PLC) as defined by EN 300 175-8 [8], clause 5.3.2 may be optionally 
implemented for ITU-T Recommendation G.722 [17]. Appendices III and IV describe packet loss concealment 
solutions extending the ITU-T Recommendation G.722 [17] decoder. These PLC algorithms may be optionally 
implemented to improve voice quality in degraded transmission conditions where packets/frames may be lost (in IP 
network or on DECT air interface). 

NOTE 1 : Both appendices meet the same quality requirements but address two different quality/complexity trade 
offs: 

1) Appendix III aims at maximizing the robustness at a price of additional complexity. 

2) Appendix IV proposes an optimized complexity/quality trade off with almost no additional 
complexity compared with ITU-T Recommendation G.722 [17] normal decoding (0,07 WMOPS). 

Since ITU-T Recommendation G.722 [17] does not incorporate any mechanism to cope with lost frames/packets, the 
use of a PLC algorithm is strongly recommended to avoid annoying effects in case of packet/frame losses. 

NOTE 2: ITU-T Recommendation G.729.1 [18] already incorporates a packet loss concealment mechanism. 

Detection of Modem/fax tone [NG1.SC.8]: detection of the 1 100 Hz, 1 300 Hz and 2 100 Hz standard tones 
indicating a fax/modem transmission and answering, as defined by EN 300 175-8 [8] clause 5.2.2. The main utility of 
this function is the switching of codecs to transparent PCM (ITU-T Recommendation G.71 1 [16]) in order to facilitate 
modem/fax transmission. The tone detection can also be used to de-activate echo suppression if present. 

Codec selection and switching [NG1.SC.9]: to handle several codecs (at least ITU-T Recommendation G.726 [15] and 
ITU-T Recommendation G.722 [17]), New Generation DECT will support a codec selection and switching mechanism. 
This may consequently allow the use of other codecs that could be specified in next releases as additional optional 
codecs according to future application or interoperability needs. 

PP Audio type la ("classic GAP" handset) [NGl.SC.lO]: Audio specification for a general purpose 3,1 kHz 

telephony handset as defined by EN 300 175-8 [8], clause 7.2.3. 
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PP audio type lb ("improved GAP" handset) [NGl.SC.ll]: Audio specification for a general purpose 3,1 kHz 
telephony handset with improved TCLw, as defined by EN 300 175-8 [8], clause 7.2.4. It is compatible with VoIP and 
long delay networks. 

PP audio type Ic (HATS tested, 3,1 kHz handset) [NG1.SC.12]: Audio specification for a general purpose 3,1 kHz 
telephony handset based on the new HATS methodology, as defined by EN 300 175-8 [8], clause 7.2.5. It includes 
strong echo suppression (TCLw) requirements and is compatible with VoIP and long delay networks. 

PP audio type Id (HATS tested, 3,1 kHz "improved" handset) [NG1.SC.13]: Audio specification for a general 
purpose 3,1 kHz telephony handset based on the new HATS methodology with improved quality, as defined by 
EN 300 175-8 [8], clause 7.2.6. It includes strong echo suppression (TCLw) requirements and is compatible with VoIP 
and long delay networks. This type has a more demanding acoustic specification, providing superior subjective quality. 
In practice, this means better electro-acoustic components (speaker, microphone), electronics and signal processing. 

PP Audio type 2a (ITU-T P.311 7 kHz handset) [NG1.SC.14]: Audio specification for a wideband, 7 kHz service, 
handset based on the ITU-T Recommendation P.31 1 [i.5], as defined by EN 300 175-8 [8], clause 7.2.9. 

PP Audio type 2b (HATS 7 kHz handset) [NG1.SC.15]: Handset for 7 kHz service (wideband), based on HATS 
methodology, as defined by EN 300 175-8 [8], clause 7.2.10. It includes strong echo suppression (TCLw) requirements 
and is compatible with VoIP and long delay networks. 

PP Audio type 2c (HATS 7 kHz "improved" handset) [NG1.SC.16]: Handset for 7 kHz service (wideband), based 
on HATS methodology, with improved quality, as defined by EN 300 175-8 [8], clause 7.2.11. It includes strong echo 
suppression (TCLw) requirements and is compatible with VoIP and long delay networks. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

PP audio type 3a (HATS tested, 3,1 kHz handsfree) [NG1.SC.17]: Audio specificafion for a Narrowband (3,1 kHz) 
handsfree device as defined by EN 300 175-8 [8], clause 7.2.7. This type applies to handsfree devices operating with an 
open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz - 3,4 kHz) frequency range, and it is defined based on HATS methodology. 

PP audio type 3b (HATS tested, 3,1 kHz "improved" handsfree) [NG1.SC.18]: Audio specification for a 
Narrowband (3,1 kHz) handsfree device, improved quality version, as defined by EN 300 175-8 [8], clause 7.2.8. This 
type applies to handsfree devices operating with an open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz - 3,4 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

PP Audio type 4a (HATS 7 kHz handsfree) [NG1.SC.19]: Wideband (7 kHz) handsfree device, as defined by 
EN 300 175-8 [8], clause 7.2.12. This type applies to handsfree devices operating with an open loudspeaker and 
microphone. The profile applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard wideband handset implementing profiles 2a, 2b or 2c, but with the option to operate in handsfree 
mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 
It provides (150 Hz - 7 kHz) frequency range, and it is defined based on HATS methodology. 
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PP Audio type 4b (HATS 7 kHz "improved" handsfree) [NG1.SC.20]: Wideband (7 kHz) handsfree device, 
improved quality version, as defined by EN 300 175-8 [8], clause 7.2.13. This type applies to handsfree devices 
operating with an open loudspeaker and microphone. The profile applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard wideband handset implementing profiles 2a, 2b or 2c, but with the option to operate in handsfree 
mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (150 Hz - 7 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

PP Audio type 5a (Super wideband 14 kHz) [NG1.SC.21]: Handset for 14 kHz service (super wideband), as defined 

by EN 300 175-8 [8], clause 7.2.14. 

PP Audio type 5b (Super wideband 14 kHz, handsfree) [NG1.SC.22]: Handsfree device for 14 kHz service (super 
wideband), as defined by EN 300 175-8 [8], clause 7.2.15. 

FP audio type lb ("new ISDN" 3,1 kHz) [NG1.SC.23]: Audio specification for a DECT FP supporting narrowband 
service and providing a digital 64 kbit/s G.71 1 interface, typically (but not necessarily) an ISDN connection, new 
specification, as defined by EN 300 175-8 [8], clause 7.3.3. 

NOTE 3: FP Audio type la ("classic ISDN", 3,1 kHz FP, see EN 300 175-8 [8]) is not to be used in in New 

Generation DECT equipment. Instead of it, FP type lb should be used in NG-DECT FPs with ISDN or 
digital circuit-switch interfaces. 

PP echo canceller for FP, narrowband (3,1 kHz) service [NG1.SC.24]: Auxiliary feature for FPs consisting on echo 
canceller for handling the echo generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.2. Only 
narrowband echo cancellation capability is required for this feature. 

PP echo supressor for FP, narrowband (3,1 kHz) service [NG1.SC.25]: Auxiliary feature for FPs consisting on 
echo supressor for handling the echo generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.3. Only 
narrowband capability is required for this feature. 

FP audio type 2 (analog PSTN 3,1 kHz) [NG1.SC.26]: Audio specification for a DECT FP supporting narrowband 
service and providing an analog 2-wire PSTN interface. As defined by EN 300 175-8 [8], clause 7.3.4. 

FP audio type 3 (VoIP 3,1 kHz) [NG1.SC.27]: Audio specification for a DECT FP supporting narrowband service and 
providing a VoIP interface, with codecs G.71 1 (typically) or G.726 on top of it. As defined by EN 300 175-8 [8], 
clause 7.3.5. 

FP Audio type 4 (ISDN, wideband) [NG1.SC.28]: Audio specification for a DECT FP supporting wideband service 
and providing a digital 64 kbit/s interface, typically (but not necessarily) an ISDN connection, with a wideband codec 
such as G.722, MPEG, etc. As defined by EN 300 175-8 [8], clause 7.3.6. 

FP Audio type 5 (VoIP wideband) [NG1.SC.29]: Audio specification for a DECT FP supporting wideband service 
and providing a VoIP interface, with a wideband codec on top such as G.722, MPEG, etc. As defined by 
EN 300 175-8 [8], clause 7.3.8. 

PP echo canceller for FP, wideband (7 kHz) service [NG1.SC.30]: Auxiliary feature for FPs consisting on echo 
canceller for handling the echo generated by PPs type 2a. As defined by EN 300 175-8 [8], clause 7.4.2. Only wideband 
echo cancellation capability is required for this feature. 

PP echo supressor for FP, wideband (7 kHz) service [NG1.SC.31]: Auxiliary feature for FPs consisting on echo 
supressor for handling the echo generated by PPs type 2a. As defined by EN 300 175-8 [8], clause 7.4.3. Only wideband 
echo cancelation capability is required for this feature. 

FP audio type 6a (internal call) [NG1.SC.32]: This type of audio specification applies to the case of internal call 
inside a DECT FP or a DECT system without any external interface. This type applies to any service. As defined by 
EN 300 175-8 [8], clause 7.3.8. 
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FP audio type 6b (internal conference) [NG1.SC.33]: This type of audio specification applies to the case of 3-party 
or muhi-party conference inside a DECT FP or a DECT system with or without an external interface. Applies to any 
service. As defined by EN 300 175-8 [8], clause 7.3.9. 

Adaptive volume control for FP [NG1.SC.34]: Accessory feature for FPs consisting on an adaptive volume control 
depending on the level of environmental noise at the PP. The gain variation shall be symmetrical. As described in 
EN 300 175-8 [8], clause 7.6 and informative annex D. 



D.2 Services and features defined in EN 300 444 (GAP) 

The following informative annex shows the features and MAC/DLC services defined in EN 300 444 [12] (GAP), many 
of them are reused in the present document. This list is informative, and shows the status in EN 300 444 (VI. 5.1). In 
case of changes or divergences the original definitions at EN 300 444 [12] (GAP) shall rule. 

D.2.1 GAP Network (NWK) features (clause 4.1 of EN 300 444) 

outgoing call [N.l]: call initiated at a DECT PP. 

off-hook [N.2]: ability to indicate the action of going off-hook, e.g. to start call setup or accept a call. 

on-hook (FULL Release) [N.3]: ability to indicate the action of going on-hook (e.g. to terminate a call) and fully 
release the radio resource. 

dialled digits (basic) [N.4]: capabiUty to dial digits to 9, *, #. 

register recall [N.5]: ability of the PP to request the invocation of the supplementary service "register recall" over the 

DECT interface and the ability of the FP to transmit the request to the local network. 

Register recall means to seize a register (with dial tone) to permit input of further digits or other action. 

go to DTMF signalling (defined tone length) [N.6]: go to DTMF signalling with defined tone length. 

pause (dialling pause) [N.7]: ability to generate or indicate a dialling pause, e.g. to await further dial tone. 

incoming call [N.8]: call received at a DECT PP. 

authentication of PP [N.9]: process by which the identity of a DECT PP is checked by the FP. 

authentication of user [N.IO]: process by which the identity of a user of a DECT PP is checked by the FP. The User 
Personal Identification (UPI), a personal identification of to 8 digits, manually entered by the user, is used for user 
authentication. 

location registration [N.ll]: facility whereby a PP can be registered with a FP or a cluster of FPs such that incoming 
calls, radio pages or messages may be routed to it. 

on-air key allocation [N.12]: capability to transform Authentication Code (AC) into User Authentication Key (UAK) 
using the key allocation procedure. 

identification of PP [N.13]: ability for the FP to request and PP to provide specific identification parameters. 

service class indication/assignment [N.14]: assignment by the FP to PP of the service class and indication to the FP by 
the PP of the contents of its service class. 

alerting [N.15]: activates or deactivates alerting at the PP using any appropriate indication. 

ZAP [N.16]: ability first to assign and then to re-program the account data held in the PP so that access rights may be 
suspended subject to the conditions set by the service provider being met, coupled with the ability to re-program the 
account data again to reinstate access rights once these conditions have been met. 

One ZAP field shall be provided per account field. The PP has the right to authenticate the FP prior to the execution of 
ZAP suspend. 

encryption activation FT initiated [N.17]: activation of the encryption process requested by FT. 
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subscription registration procedure on-air [N.18]: standardized procedure for loading subscription registration data 
into a PP in real time over the air-interface. 

link control [N.19]: ability to request, accept, maintain and release a data link for the purposes of a NWK layer 
procedure. 

terminate access rights FT initiated [N.20]: ability of the FP to delete a subscription in the PP. 

partial release [N.21]: ability to release an established or in progress Call Control (CC) call whilst retaining the radio 
resource for the purpose of accessing further services. 

go to DTMF (infinite tone length) [N.22]: go to DTMF signalUng, indicating infinite DTMF tone duration. 

go to pulse [N.23]: go to pulse (decadic) signalling. 

signalling of display characters [N.24]: transmission to the PP of characters to be displayed on the user's PP display 
(if provided). 

display control characters [N.25]: characters sent to the PP to control the user's display in the PP (if provided) 
Such characters include cursor control, clear screen, home, flash, inverse video, etc. 

authentication of FT [N.26]: process by which the identity of a FP is checked by the PP. 

encryption activation PT initiated [N.27]: activation of the encryption process suggested by PT. 
The real time start of ciphering is done in the MAC layer and is always initiated by the PT. 

encryption deactivation FT initiated [N.28]: deactivation of the encryption process requested by FT. 
The real time stop of ciphering is done in the MAC layer and is always initiated by the PT. 

encryption deactivation PT initiated [N.29]: deactivation of the encryption process suggested by PT. 
The real time stop of ciphering is done in the MAC layer and is always initiated by the PT. 

Calling Line Identification Presentation (CLIP) [N.30]: ability to provide the calling party number to the called party 
before accepting the call. 

internal call [N.31]: call between 2 users that does not make use of the local network resources. 
This is typically useful in residential environments. 

service call [N.32]: call initiated by a DECT PT for entering of FT related service and adjustment procedures in a 

transparent way. 

After having sent the service call indication, the PT behaves according to the rules of a normal call. 

Enhanced U- plane connection [N.33]: ability of the FT to initiate connection of the U- plane during call 
establishment or release e.g. to facilitate the provision of in band tones or announcements. 

Calling Name Identification Presentation (CNIP) [N.34]: ability to provide the calling party name to the called party 
before accepting the call. 

D.2.2 GAP Speech coding and audio features (clause 4.2 of 
EN 300 444) 

For the purposes of the present document the following definitions shall apply: 

G.726 32 kbit/s ADPCM [SC.l]: ITU-T Recommendation G.726 [15] narrow band codec as defined by 

EN 300 175-8 [8] clause 5.1. 

PP audio type la ("classic GAP" handset) [SC.2]: Audio specification for a general purpose 3,1 kHz telephony 

handset as defined by EN 300 175-8 [8], clause 7.2.3. 

PP audio type lb ("improved GAP" handset) [SC.3]: Audio specification for a general purpose 3,1 kHz telephony 
handset with improved TCLw, as defined by EN 300 175-8 [8], clause 7.2.4. It is compatible with VoIP and long delay 
networks. 



£75/ 



196 ETSI TS 102 527-3 VI. 1.1 (2008-06) 

PP audio type Ic (HATS tested, 3,1 kHz handset) [SC.4]: Audio specification for a general purpose 3,1 kHz 
telephony handset based on the new HATS methodology, as defined by EN 300 175-8 [8], clause 7.2.5. It includes 
strong echo suppression (TCLw) requirements and is compatible with VoIP and long delay networks. 

PP audio type Id (HATS tested, 3,1 kHz "improved" handset) [SC.5]: Audio specification for a general purpose 
3,1 kHz telephony handset based on the new HATS methodology with improved quality, as defined by 
EN 300 175-8 [8], clause 7.2.6. It includes strong echo suppression (TCLw) requirements and is compatible with VoIP 
and long delay networks. This type has a more demanding acoustic specification, providing superior subjective quality. 
In practice, this means better electro-acoustic components (speaker, microphone), electronics and signal processing. 

PP audio type 3a (HATS tested, 3,1 kHz handsfree) [SC.6]: Audio specification for a Narrowband (3,1 kHz) 
handsfree device as defined by EN 300 175-8 [8], clause 7.2.7. This type applies to handsfree devices operating with an 
open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz - 3,4 kHz) frequency range, and it is defined based on HATS methodology. 

PP audio type 3b (HATS tested, 3,1 kHz "improved" handsfree) [SC.7]: Audio specification for a Narrowband 
(3,1 kHz) handsfree device, improved quality version, as defined by EN 300 175-8 [8], clause 7.2.8. This type applies to 
handsfree devices operating with an open loudspeaker and microphone. The type applies to either: 

1) specific PPs designed to operate in handsfree mode; 

2) standard handset implementing types la, lb, Ic or Id, but with the option to operate in handsfree mode; and 

3) handsfree accessory devices connected to a handset by any wired or wireless technology. 

It provides (300 Hz - 3,4 kHz) frequency range, and it is defined based on HATS methodology. This type has a more 
demanding acoustic specification, providing superior subjective quality. In practice, this means better electro-acoustic 
components (speaker, microphone), electronics and signal processing. 

FP audio type la ("classic ISDN" 3,1 kHz) [SC.8]: Audio specification for a DECT FP supporting narrowband 
service and providing a digital 64 kbit/s G.711 interface, typically (but not necessarily) an ISDN connection, classic 
specification, as defined by EN 300 175-8 [8], clause 7.3.2. It is recommended to use FP type lb instead of type la. 

FP audio type lb ("new ISDN" 3,1 kHz) [SC.9]: Audio specification for a DECT FP supporting narrowband service 
and providing a digital 64 kbit/s G.71 1 interface, typically (but not necessarily) an ISDN connection, new specification, 
as defined by EN 300 175-8 [8], clause 7.3.3. It is recommended to use FP type lb instead of type la. 

PP echo canceller for FP [SC.IO]: Auxiliary feature for FPs consisting on echo canceller for handling the echo 
generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.2. Only narrowband echo cancellation capability 
is required. 

PP echo supressor for FP [SC.ll]: Auxiliary feature for FPs consisting on echo supressor for handling the echo 
generated by PPs type la. As defined by EN 300 175-8 [8], clause 7.4.3. Only narrowband capability is required. 

FP audio type 2 (analog PSTN 3,1 kHz) [SC.12]: Audio specification for a DECT FP supporting narrowband service 
and providing an analog 2-wire PSTN interface. As defined by EN 300 175-8 [8], clause 7.3.4. 

FP audio type 3 (VoIP 3,1 kHz) [SC.13]: Audio specification for a DECT FP supporting narrowband service and 
providing a VoIP interface, with codecs G.71 1 (typically) or G.726 on top of it. As defined by EN 300 175-8 [8], 
clause 7.3.5. 

FP audio type 5a (internal call) [SC.14]: This type of audio specification applies to the case of internal call inside a 
DECT FP or a DECT system without any external interface. This type applies to any service. As defined by 

EN 300 175-8 [8], clause 7.3.8. 

FP audio type 5b (internal conference) [SC.15]: This type of audio specification applies to the case of 3-party or 
multi-party conference inside a DECT FP or a DECT system with or without an external interface. Applies to any 
service. As defined by EN 300 175-8 [8], clause 7.3.9. 
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Adaptive volume control for FP [SC.16]: Accesory feature for FPs consisting on an adaptive volume control 
depending on the level of environmental noise at the PP. The gain variation shall be symmetrical. As described in 
EN 300 175-8 [8], (detailed descriptions for each type of FP in clause 7.6, and examples of settings in annex D). 

D.2.3 GAP Application features (clause 4.3 of EN 300 444) 

AC to bitstring mapping [A.l]: Mapping of the AC into a bitstring. 

multiple subscription registration [A.2]: Ability of PP to store more than one subscription. 

manual entry of the Portable Access Rights Key (PARK) [A.3]: Ability of the PP to accept a manual entry of the 
PARK for ensuring attachment to the right FP in a physical area covered by many providers. 

terminal identity number assignment in mono-cell system [A.4]: Ability to assign to each PT a terminal identity 
number. 

D.2.4 DLC service definitions (clause 5.1 of EN 300 444) 

LAPC class A service and Lc [D.l]: single frame acknowledged C-plane data link service providing a single data link 
between one FT and one PT. 

The higher layer information is segmented (if necessary) and transmitted in numbered frames. The Lc provides frame 
delimiting, transparency and frame synchronization. 

Cs channel fragmentation and recombination [D.2]: Lc service providing channel dependant fragmentation (by 
means of dividing a LAPC data unit into more than one service data units for delivery to the MAC layer Cs logical 
channel) and recombination (by means of joining several service units received from the MAC layer Cs logical channel 
into a LAPC data unit) 

broadcast Lb service [D.3]: simplex point-to-multipoint transmission using simple fixed length DLC frames providing 
a restricted broadcast service in direction FP to PP(s). 

intra-cell voluntary connection handover [D.4]: internal handover process provided and initiated by the DLC layer 
(e.g. as a result of continued poor quality of service from the MAC layer), whereby one set of DLC entities (C-plane 
and U-plane) can re-route data from one MAC connection to a second new MAC connection in the domain of the same 
cell, while maintaining the service provided to the NWK layer. 

intercell voluntary connection handover [D.5]: internal handover process provided and initiated by the DLC layer 
(e.g. as a result of continued poor quality of service from the MAC layer), whereby one set of DLC entities (C-plane 
and U-plane) can re-route data from one MAC connection to a second new MAC connection not in the domain of the 
same cell, while maintaining the service provided to the NWK layer. 

encryption activation [D.6]: transporting the NWK layer encryption request and the cipher key to the MAC layer, 
thereby enabling the encryption process in the MAC layer. 

LUl TRansparent Unprotected service (TRUP) class 0/min_delay [D.7]: transparent unprotected service 
introducing minimum delay between the higher layers and the MAC layer. 

May be used for speech and non-speech applications. Speech transmission shall only use the class 0/min_delay 
operation over a single bearer MAC connection. Data integrity is not guaranteed. No error protection is applied, and 
octets may be lost, erroneous or duplicated. The continuous higher layer data is fragmented for delivery to the In logical 
channel in the transmission direction, and recombined from the I^ logical channel in the receiving direction. 

FUl [D.8]: offers a defined fixed length frame structure and buffering functions for transmission of U-plane data to the 
MAC layer (at the transmit side) or accept of data from the MAC layer (at the receiving side) on demand and with 
minimum delay. Used for speech but may be used for more general data purposes. 

encryption deactivation [D.9]: transporting the NWK layer encryption deactivation request to the MAC layer, thereby 
disabling the encryption process in the MAC layer. 
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D.2.5 GAP MAC service definitions (clause 5.2 of EN 300 444) 

general [M.l]: set of basic requirements regarding data formats, multiplexing, CRC usage, scanning and locking, 
which are prerequisites to communication between peer MAC entities. 

continuous broadcast [M.2]: simplex service from FT to PT whereby the FT maintains at least one bearer with 

continuous transmissions. 

The PT can use the information carried in this bearer to lock to the FT and to obtain knowledge about the FT. 

paging broadcast [M.3]: service whereby the identities of specific PTs can be broadcast by the FT. This service is 
normally used by the FT to request a specific PT to set up a link to the FT. 

basic connection [M.4]: service providing connection between FT and PT consisting of one full slot duplex bearer 
supporting the In_minimum_delay data service (i.e. speech). 

Only one basic connection may exist between a FT and particular PT (except during connection handover). The service 
includes the means for setting-up and releasing the required bearer(s). 

Cs higher layer signalling [M.5]: low rate connection oriented data service with ARQ using the Cs channel to transfer 
higher layer signalling data. 

quality control [M.6]: provides means for monitoring and controlling the radio link quality. 

encryption activation [M.7]: service providing means for enabling the encryption whereby on demand all higher layer 
data (including speech) is transferred across the AI in an encrypted form. 
Always initiated by the PT. 

extended frequency allocation [M.8]: service which allows a FT to support frequencies in addition to the standard 
DECT frequencies. 

bearer handover - intra-cell [M.9]: internal MAC process whereby data transfer (C channel and I channel) is switched 
from one duplex bearer to another in the domain of the same cell while maintaining the service to the DLC layer. 

bearer handover - inter-cell [M.IO]: internal MAC process whereby data transfer (C channel and I channel) is 
switched from one duplex bearer to another not in the domain of the same cell while maintaining the service to the DLC 
layer. 

connection handover - intra-cell [M.ll]: in the MAC layer, it is the process enabling setting up a new basic 
connection in the domain of the same cell to support connection handover at the DLC layer. 

connection handover - inter-cell [M.12]: in the MAC layer, it is the process enabling setting up a new basic 
connection not in the domain of the same cell to support connection handover at the DLC layer. 

Secondary Access Rights Identity (SARI) support [M.13]: ability to support, in addition to the primary Access 
Rights Identity (ARI), secondary ARIs that the FT broadcasts less frequently than PARIs. 

These may be used to reflect an inter-operators agreement allowing a portable to access more than one operator or 
services through FT. 

encryption deactivation [M.14]: service providing means for disabling the encryption whereby on demand the process 
of transmitting higher layer data (including speech) across the AI in encrypted form is to be cancelled (a connection 
release automatically disables ciphering). 



D.3 GAP Feature/service to procedure mapping tables 

The following informative annex shows the features/service to procedure mapping tables as defined in EN 300 444 [12] 
(GAP), that are reused in the present document (unless other specification is given). This list is informative, and shows 
the status in EN 300 444 [12]. In case of changes or divergences the original tables at EN 300 444 [12] (GAP) shall 
rule. 
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D.3.1 GAP NWK feature to procedure mapping table (clause 6.8.1 
of EN 300 444) 

Table D.I : NWK feature to procedure mapping (table 5 of EN 300 444) 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 1 










R/B 


P 


N.I Outgoing call 




4.1 


M 


M 


M 


Outgoing call request 


8.2 


M 


M 


M 


Overlap sending 


8.3 


M 








Outgoing call proceeding 


8.4 


M 








Outgoing call confirmation 


8.5 


M 








Outgoing call connection 


8.6 


M 


M 


M 


Sending keypad information 


8.10 


M 


M 


M 


N.2 Off Hook 




4.1 


M 


M 


M 


Outgoing call request 


8.2 


M 


M 


M 


Incoming call connection 


8.15 


M 


M 


M 


N.3 On Hook (full release) 




4.1 


M 


M 


M 


Normal call release 


8.7 


M 


M 


M 


Abnormal call release 


8.8 


M 


M 


M 


N.4 Dialled digits (basic) 




4.1 


M 


M 


M 


Sending keypad information 


8.10 


M 


M 


M 


N.5 Register recall 




4.1 


M 








Sending keypad information 


8.10 


M 


M 


M 


N.6 Go to DTMF signalling 
(defined tone length) 




4.1 


M 





M 


Sending keypad information 


8.10 


M 


M 


M 


N.7 Pause (dialling pause) 




4.1 


M 








Sending keypad information 


8.10 


M 


M 


M 


N.8 Incoming call 




4.1 


M 


M 


M 


Incoming call request 


8.12 


M 


M 


M 


Incoming call confirmation 


8.13 


M 


M 


M 


PT alerting 


8.14 


M 


M 


M 


Incoming call connection 


8.15 


M 


M 


M 


N.9 Authentication of the PP 




4.1 


M 





M 


Authentication of PT 


8.24 


M 


M 


M 


N10 Authentication of the user 




4.1 


M 








Authentication of user 


8.25 


M 


M 


M 


N.11 Location registration 




4.1 


M 





M 


Location registration 


8.28 


M 


M 


M 


Location update 


8.29 


M 








Terminal Capability indication 


8.17 











N.12 On air key allocation 




4.1 


M 








Key allocation 


8.32 


M 


M 


M 


N.13 Identification of PP 




4.1 


M 








Identification of PT 


8.22 


M 


M 


M 


N.14 Service class 
indication/assignment 




4.1 


M 





M 


Obtaining access rights 


8.30 


M 


M 


M 


Terminal Capability indication 


8.17 











Authentication of PT 


8.24 


M 


M 


M 


N. 15 Alerting 




4.1 


M 


M 


M 


PT alerting 


8.14 


M 


M 


M 


N.16ZAP 




4.1 


M 








Obtaining access rights 


8.30 


M 


M 


M 


Terminal Capability indication 


8.17 











Incrementing the ZAP value 


8.26 


M 


M 


M 


Authentication of FT 


8.23 





M 


M 


N.I 7 Encryption activation FT 
initiated 




4.1 


M 





M 


Cipher-switching initiated by FT 


8.33 


M 


M 


M 


Storing the Derived Cipher Key (DCK) 


8.27 


M 


M 


M 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 










R/B 


P 


N.18 Subscription registration user 
procedure on-air 




4.1 


M 


M 


M 


Obtaining access rights 


8.30 


M 


M 


M 


Terminal Capability indication 


8.17 











N.I 9 Link control 




4.1 


M 


M 


M 


Indirect FT initiated link establishment 


8.35 


M 


M 


M 


Direct PT initiated link establishment 


8.36 


M 


M 


M 


Link release "normal" 


8.37 


M 


M 


M 


Link release "abnormal" 


8.38 


M 


M 


M 


Link release "maintain" 


8.39 


M 


M 


M 


N.20 Terminate access rights FT 
initiated 




4.1 


M 








FT terminating access rights 


8.31 


M 


M 


M 


Authentication of FT 


8.23 





M 


M 


N.21 Partial release 




4.1 











Partial release 


8.9 


M 


M 


M 


N.22 Go to DTMF (infinite tone 
length) 




4.1 











Sending keypad information 


8.10 


M 


M 


M 


N.23 Go to Pulse 




4.1 











Sending keypad information 


8.10 


M 


M 


M 


N.24 Signalling of display 
characters 




4.1 











Display 


8.16 


M 


M 


M 


Terminal capability indication 


8.17 


M 


M 


M 


N.25 Display control characters 




4.1 











Display 


8.16 


M 


M 


M 


Terminal capability indication 


8.17 


M 


M 


M 


N.26 Authentication of FT 




4.1 











Authentication of FT 


8.23 


M 


M 


M 


N.27 Encryption activation PT 
initiated 




4.1 











Cipher-switching initiated by PT 


8.34 


M 


M 


M 


Storing the DCK 


8.27 


M 


M 


M 


N.28 Encryption deactivation FT 
initiated 




4.1 











Cipher-switching initiated by FT 


8.33 


M 


M 


M 


N.29 Encryption deactivation PT 
initiated 




4.1 











Cipher-switching initiated by PT 


8.34 


M 


M 


M 


N.30 Calling Line Identification 
Presentation (CLIP) 




4.1 











Incoming call request 


8.12 


M 


M 


M 


Calling Line Identification Presentation 


8.41 


M 


M 


M 


N.31 Internal call 




4.1 











Internal call setup 


8.18 


M 


M 


M 


Internal call keypad 


8.19 


M 








Internal call CLIP 


8.43 











Internal call CNIP 


8.44 











N.32 Service call 




4.1 











Service call setup 


8.20 


M 


M 


M 


Service call keypad 


8.21 


M 








N.33 Enhanced U- plane 
connection 




4.1 











Enhanced FT initiated U- plane 
connection 


8.40 


M 


M 


M 


N.34 Calling Name Identification 
Presentation (CNIP) 




4.1 











Calling Name Identification Presentation 
(CNIP) Indication 


8.42 


M 


M 


M 
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D.3.2 GAP DLC service to procedure mapping table (clause 6.8.2 
of EN 300 444) 

Table D.2: DLC service to procedure mapping (table 6 of EN 300 444) 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 1 










R/B 


P 


D.I LAPC class A service and Lc 




5.1 


M 


M 


M 


Class A link establishment 


9.1 


M 


M 


M 


Class A acknowledged information 
transfer 


9.2 


M 


M 


M 


Class A link release 


9.3 


M 


M 


M 


Class A link re-establishment 


9.4 


M 


M 


M 


D.2 Cs channel fragmentation and 
recombination 




5.1 


M 


M 


M 


Cs channel fragmentation and 
recombination 


9.5 


M 


M 


M 


D.3 Broadcast Lb service 




5.1 


M 


M 


M 


Normal broadcast 


9.6 


M 


M 


M 


D.4 Intra-cell voluntary connection 
handover 




5.1 


M 


C601 


C601 


Class A basic connection handover 


9.7 


M 


M 


M 


D.5 Inter-cell voluntary connection 
handover 




5.1 


M 








Class A basic connection handover 


9.7 


M 


M 


M 


D.6 Encryption activation 




5.1 


M 


C603 


M 


Encryption switching 


9.8 


M 


M 


M 


D.7 LU1 TRUP Class 0/min_delay 




5.1 


M 


M 


M 


U-plane Class 0/min delay 


9.9 


M 


M 


M 


D.8 FU1 




5.1 


M 


M 


M 


FU1 frame operation 


9.10 


M 


M 


M 


D.9 Encryption deactivation 




5.1 


C602 


C602 


C602 


Encryption switching 


9.8 


M 


M 


M 


C601: IF service M.9 THEN ELSE M. 

C602: IF feature N.29 OR N.28 THEN M ELSE 1. 

C603: IF feature N.I 7 OR N.27 THEN M ELSE 1. 
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D.3.3 GAP MAC service to procedure mapping table (clause 6.8.3 
of EN 300 444) 

Table D.3: MAC service to procedure mapping (table 7 of EN 300 444) 



Service/Procedure mapping 




Status 


Service 


Procedure 


Reference 


PT 


FT 1 










R/B 


P 


M.1 General 




5.2 


M 


M 


M 


General 


10.1 


M 


M 


M 


M.2 Continuous broadcast 




5.2 


M 


M 


M 


Downlink broadcast 


10.2 


M 


M 


M 


Higher layer information FP broadcast 


13.6 


M 


M 


M 


M.3 Paging broadcast 




5.2 


M 


M 


M 


Paging broadcast 


10.3 


M 


M 


M 


Higher layer information FP broadcast 


13.6 


M 


M 


M 


IVI.4 Basic connections 




5.2 


M 


M 


M 


Setup of basic connection, basic bearer 
setup (A-field) 


10.4 


M 


M 


M 


Connection/bearer release 


10.5 


M 


M 


M 


M.5 Cs higher layer signalling 




5.2 


M 


M 


M 


Cs channel data 


10.8 


M 


M 


M 


02 bit setting 


10.9 


M 


M 


M 


M.6 Quality control 




5.2 


M 


M 


M 


RFPI handshake 


10.10 


M 


M 


M 


Antenna diversity 


10.11 


M 








Sliding collision detection 


10.12 





M 


M 


M.7 Encryption activation 




5.2 


M 


C704 


M 


Encryption process - initialization and 
synchronization 


10.13 


M 


M 


M 


Encryption mode control 


10.14 


M 


M 


M 


Handover encryption process 


10.15 


M 


M 


M 


IVI.8 Extended frequency 
allocation 




5.2 


M 








Extended frequency allocation 


10.16 


M 


M 


M 


IVI.9 Bearer handover, intra-cell 




5.2 


M 


C701 


C701 


Bearer handover request 


10.6 


M 


M 


M 


IVI.10 Bearer handover, inter-cell 




5.2 


M 








Bearer handover request 


10.6 


M 


M 


M 


M.11 Connection handover, intra- 
cell 




5.2 


M 


C702 


C702 


Connection handover request 


10.7 


M 


M 


M 


M.1 2 Connection handover, inter- 
cell 




5.2 


M 








Connection handover request 


10.7 


M 


M 


M 


M.1 3 SARI support 




5.2 


M 








Downlink broadcast 


10.2 


M 


M 


M 


Higher layer information FP broadcast 


13.6 


M 


M 


M 


M.1 4 Encryption deactivation 




5.2 


C703 


C703 


C703 


Encryption mode control 


10.14 


M 


M 


M 


C701 
C702 
C703 
C704 


IF service M.1 1 THEN ELSE M. 

IF service M.9 THEN ELSE M. 

IF feature N.29 OR N.28 THEN M ELSE 1. 

IF feature N.17 OR N.27 THEN M ELSE 1. 
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D.3.4 GAP Application feature to procedure mapping table 
(clause 6.8.4 of EN 300 444) 

Table D.4: Application feature to procedure mapping table (table 8 of EN 300 444) 



Feature/Procedure mapping 




Status 


Feature 


Procedure 


Reference 


PT 


FT 1 










R/B 


P 


A.1 AC to bitstring mapping 




4.3 


M 


C801 


M 


AC to bitstring mapping 


14.2 


M 


M 


M 


A.2 Multiple subscription 
registration 




4.3 


M 


N/A 


N/A 


Subscription control 


14.1 


M 


N/A 


N/A 


A.3 Manual entry of the PARK 




4.3 





N/A 


N/A 


Manual entry of the PARK 


14.3 


M 


N/A 


N/A 


A.4 Terminal identity number 
assignment in mono cell system 




4.3 








N/A 


Terminal identity number assignment 


14.4 








N/A 


C801: IFfeatureN.9ORN.10ORN.12ORN.26THENMELSEN/A. 
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